Motherboard Forums


Reply
Thread Tools Display Modes

"Talking" to a "busy" application

 
 
Don Y
Guest
Posts: n/a
 
      12-07-2011, 02:53 PM
Hi,

I'm trying to come up with a (universal) scheme
by which a user can check the progress of a
(long-) running application.

You often don't want to be bothered with
"progress reports" from applications that will
chug along (reliably!) on some time-consuming
task. For the most part, you just want it
to "do its thing" without bothering you.

Some applications might be designed with the ability
to provide ongoing updates (e.g., "format 27% complete").
Some might only provide those when *invoked* with
a particular option (e.g., FTP transfer '#' progress
indicators). Some applications might chug along
until poked with a stick (e.g., SIGHUP'ing a process
and hoping it ejaculates something of meaning).

But, these approaches aren't consistent. I'm
looking for a practice that I can implement that
gives the user this information when/as he needs
it without "regrets" ("Crap! I forgot to specify
the '-progress' flag when I started the application
so now I just have to wait for it to finish...")

To that end, I'm thinking about adding a 4th
file descriptor to each process: stdin, stdout,
stderr and stdwup (What's UP?). An applcation
would (through discipline) emit status messages
periodically on the stdwup file descriptor explaining
what it is doing, how far along in the process it is,
etc. The user could then hook (or not!) that
file descriptor to view these messages. This
would allow the application to be written without
having the interactive nature of signal handling
yet still provide information about its activities
(e.g., the "shell" could cache the most recently emitted
line on that stdwup file descriptor so that it can
pass this on to the user if/when the user expresses
an interest)

A similar (the same?) mechanism can be used as a
"control channel" (stdctl?) by which commands
governing the operation of the application can be passed
to the application to modify its behavior after its
initial invocation [this would be used to address
performance issues, not "usage"]

Are there any existing systems with similar mechanisms
from which I can borrow ideas?

Thx,
--d
 
Reply With Quote
 
 
 
 
cassiope
Guest
Posts: n/a
 
      12-08-2011, 08:37 PM
On Dec 7, 6:53*am, Don Y <(E-Mail Removed)> wrote:
> Hi,
>
> I'm trying to come up with a (universal) scheme
> by which a user can check the progress of a
> (long-) running application.
>
> You often don't want to be bothered with
> "progress reports" from applications that will
> chug along (reliably!) on some time-consuming
> task. *For the most part, you just want it
> to "do its thing" without bothering you.
>
> Some applications might be designed with the ability
> to provide ongoing updates (e.g., "format 27% complete").
> Some might only provide those when *invoked* with
> a particular option (e.g., FTP transfer '#' progress
> indicators). *Some applications might chug along
> until poked with a stick (e.g., SIGHUP'ing a process
> and hoping it ejaculates something of meaning).
>
> But, these approaches aren't consistent. *I'm
> looking for a practice that I can implement that
> gives the user this information when/as he needs
> it without "regrets" ("Crap! *I forgot to specify
> the '-progress' flag when I started the application
> so now I just have to wait for it to finish...")
>
> To that end, I'm thinking about adding a 4th
> file descriptor to each process: *stdin, stdout,
> stderr and stdwup (What's UP?). *An applcation
> would (through discipline) emit status messages
> periodically on the stdwup file descriptor explaining
> what it is doing, how far along in the process it is,
> etc. *The user could then hook (or not!) that
> file descriptor to view these messages. *This
> would allow the application to be written without
> having the interactive nature of signal handling
> yet still provide information about its activities
> (e.g., the "shell" could cache the most recently emitted
> line on that stdwup file descriptor so that it can
> pass this on to the user if/when the user expresses
> an interest)
>
> A similar (the same?) mechanism can be used as a
> "control channel" (stdctl?) by which commands
> governing the operation of the application can be passed
> to the application to modify its behavior after its
> initial invocation [this would be used to address
> performance issues, not "usage"]
>
> Are there any existing systems with similar mechanisms
> from which I can borrow ideas?
>
> Thx,
> --d


It's not a universal solution - but one method I've used is to have a
thread with a socket.
You can connect to the socket, and make parameter changes, interrogate
status,
whatever capabilities you program in. It's very customizable to any
particular need.
These are on Unix/Linux systems, haven't any experience on Windows
though I
think it could be made to work there too.

On stand-alone systems, I often have a serial port that can be used
for the same
purposes. These are usually systems that regularly poll the serial
port for activity.

How would your "stdwup" file descriptor work if there could be more
than one program
running that might use this functionality?

HTH--
 
Reply With Quote
 
 
 
 
Don Y
Guest
Posts: n/a
 
      12-08-2011, 08:49 PM
Hi Cassiope,

On 12/8/2011 1:37 PM, cassiope wrote:
> On Dec 7, 6:53 am, Don Y<(E-Mail Removed)> wrote:


>> I'm trying to come up with a (universal) scheme
>> by which a user can check the progress of a
>> (long-) running application.


>> To that end, I'm thinking about adding a 4th
>> file descriptor to each process: stdin, stdout,
>> stderr and stdwup (What's UP?). An applcation
>> would (through discipline) emit status messages
>> periodically on the stdwup file descriptor explaining
>> what it is doing, how far along in the process it is,
>> etc. The user could then hook (or not!) that
>> file descriptor to view these messages. This
>> would allow the application to be written without
>> having the interactive nature of signal handling
>> yet still provide information about its activities
>> (e.g., the "shell" could cache the most recently emitted
>> line on that stdwup file descriptor so that it can
>> pass this on to the user if/when the user expresses
>> an interest)
>>
>> A similar (the same?) mechanism can be used as a
>> "control channel" (stdctl?) by which commands
>> governing the operation of the application can be passed
>> to the application to modify its behavior after its
>> initial invocation [this would be used to address
>> performance issues, not "usage"]


> It's not a universal solution - but one method I've used is to have a
> thread with a socket.
> You can connect to the socket, and make parameter changes, interrogate
> status,
> whatever capabilities you program in. It's very customizable to any
> particular need.


Yes, I currently have a "control channel" that the OS uses
to interact with each task/process. I had thought of
embelishing that mechanism but think I want/need to
create a similar, but different, channel for "less
privileged" interactions (i.e., the OS can tell the
task to do very significant things -- things that you
wouldn't want a "mere mortal/user" to tell the task).

> These are on Unix/Linux systems, haven't any experience on Windows
> though I think it could be made to work there too.


<grin> "I don't do windows."

> On stand-alone systems, I often have a serial port that can be used
> for the same
> purposes. These are usually systems that regularly poll the serial
> port for activity.


The problem here would be that which you outline below...

> How would your "stdwup" file descriptor work if there could be more
> than one program running that might use this functionality?


Essentially, the user indicates the task/process that he
is concerned with (i.e., you could have multiple instances
of the same "application") and sends a message to it's
strwup file descriptor (analagous to telnetting to
a port assigned to that particular process instance).

This does all of the demultiplexing outside of the
application(s) themselves (i.e., any message coming in on
YOUR strwup is defintely intended for you and expected to
be handled by you!).
 
Reply With Quote
 
cassiope
Guest
Posts: n/a
 
      12-09-2011, 05:09 AM
On Dec 8, 12:49*pm, Don Y <(E-Mail Removed)> wrote:
> Hi Cassiope,
>
> On 12/8/2011 1:37 PM, cassiope wrote:
>
>
>
> > On Dec 7, 6:53 am, Don Y<(E-Mail Removed)> *wrote:
> >> I'm trying to come up with a (universal) scheme
> >> by which a user can check the progress of a
> >> (long-) running application.
> >> To that end, I'm thinking about adding a 4th
> >> file descriptor to each process: *stdin, stdout,
> >> stderr and stdwup (What's UP?). *An applcation
> >> would (through discipline) emit status messages
> >> periodically on the stdwup file descriptor explaining
> >> what it is doing, how far along in the process it is,
> >> etc. *The user could then hook (or not!) that
> >> file descriptor to view these messages. *This
> >> would allow the application to be written without
> >> having the interactive nature of signal handling
> >> yet still provide information about its activities
> >> (e.g., the "shell" could cache the most recently emitted
> >> line on that stdwup file descriptor so that it can
> >> pass this on to the user if/when the user expresses
> >> an interest)

>
> >> A similar (the same?) mechanism can be used as a
> >> "control channel" (stdctl?) by which commands
> >> governing the operation of the application can be passed
> >> to the application to modify its behavior after its
> >> initial invocation [this would be used to address
> >> performance issues, not "usage"]

> > It's not a universal solution - but one method I've used is to have a
> > thread with a socket.
> > You can connect to the socket, and make parameter changes, interrogate
> > status,
> > whatever capabilities you program in. *It's very customizable to any
> > particular need.

>
> Yes, I currently have a "control channel" that the OS uses
> to interact with each task/process. *I had thought of
> embelishing that mechanism but think I want/need to
> create a similar, but different, channel for "less
> privileged" interactions (i.e., the OS can tell the
> task to do very significant things -- things that you
> wouldn't want a "mere mortal/user" to tell the task).
>
> > These are on Unix/Linux systems, haven't any experience on Windows
> > though I think it could be made to work there too.

>
> <grin> *"I don't do windows."
>
> > On stand-alone systems, I often have a serial port that can be used
> > for the same
> > purposes. *These are usually systems that regularly poll the serial
> > port for activity.

>
> The problem here would be that which you outline below...
>
> > How would your "stdwup" file descriptor work if there could be more
> > than one program running that might use this functionality?

>
> Essentially, the user indicates the task/process that he
> is concerned with (i.e., you could have multiple instances
> of the same "application") and sends a message to it's
> strwup file descriptor (analagous to telnetting to
> a port assigned to that particular process instance).
>
> This does all of the demultiplexing outside of the
> application(s) themselves (i.e., any message coming in on
> YOUR strwup is defintely intended for you and expected to
> be handled by you!).


This sounds a lot like a (named?) pipe. Whether that or a socket,
there's
nothing to keep you from restricting its capabilities. Either should
work,
and you don't have to modify the OS. If you have control channels
that
you want to protect, you should be able to keep that separate from
this new channel.
 
Reply With Quote
 
Don Y
Guest
Posts: n/a
 
      12-09-2011, 07:50 AM
Hi Cassiope,

On 12/8/2011 10:09 PM, cassiope wrote:
> On Dec 8, 12:49 pm, Don Y<(E-Mail Removed)> wrote:


[much elided]

>>> How would your "stdwup" file descriptor work if there could be more
>>> than one program running that might use this functionality?

>>
>> Essentially, the user indicates the task/process that he
>> is concerned with (i.e., you could have multiple instances
>> of the same "application") and sends a message to it's
>> strwup file descriptor (analagous to telnetting to
>> a port assigned to that particular process instance).
>>
>> This does all of the demultiplexing outside of the
>> application(s) themselves (i.e., any message coming in on
>> YOUR strwup is defintely intended for you and expected to
>> be handled by you!).

>
> This sounds a lot like a (named?) pipe.


There are significant differences.

Named pipes exist in the filesystem's namespace. M
communication channels exist in whatever namespace
the OS creates them in (i.e., they may only be visible
to specific processes).

Named pipes are explicitly created (by "someone").
By contrast, the OS sets up the std* file descriptors
*for* the process as it is being created.

Named pipes continue to exist in the namespace
after the process has terminated (by contrast,
stdin and stdout lose all meaning once the
process dies).

If nothing is plumbed to the output of the pipe,
anything pushed into it falls out. I *think* I
want/need the communication channel to hang onto
the "most recent message" (which begs the question:
"What's a mesage?") Otherwise, connecting to that
channel (to peek at the application's status)
would produce NO results -- until the application
UPDATED its status. (By contrast, if the most
recent "report" remained in the pipe, you could
always see what the app was doing "most recently")

ACL's for filesystem objects tend to be pretty coarse.
Granting access to "status" while denying access to
"control" can get cumbersome (though you could work
around this systematically by creating a separate
gid for each pipe and placing the uid's of the
tasks authorized to access that pipe in that gid)

> Whether that or a socket, there's
> nothing to keep you from restricting its capabilities.


Yes. But, if I push two different types of information
(and control) down the same channel, I need some other
authentication mechanism -- i.e., access to the channel
for one type of information needs to NOT, also, imply
capabilities for the *other* type of information.

> Either should work,
> and you don't have to modify the OS. If you have control channels
> that
> you want to protect, you should be able to keep that separate from
> this new channel.


 
Reply With Quote
 
 
 
Reply

Thread Tools
Display Modes

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is On
HTML code is Off
Trackbacks are On
Pingbacks are On
Refbacks are Off


Similar Threads
Thread Thread Starter Forum Replies Last Post
How to add application to "open with" application list luminous_bipeds Apple 5 09-01-2006 01:16 PM
Application Folder acts like an Application nikodemus.karlsson@gmail.com Apple 0 08-13-2005 06:21 PM
Is E6900 == SF6900? Application(SF6800) -->Application(SF6900) ?? qazmlp Sun Hardware 6 08-08-2004 02:21 PM
Choosing recognizers on an application-by-application basis Craig Olinsky Tablet PC 3 03-06-2004 03:18 AM
Intel® Application Accelerator RAID Edition Gabus Abit 10 01-08-2004 11:46 PM


All times are GMT. The time now is 10:13 AM.


Welcome!
Welcome to Motherboard Point
 

Advertisment