"Talking" to a "busy" application
- From: Don Y <not.to.be@xxxxxxxx>
- Date: Wed, 07 Dec 2011 07:53:03 -0700
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
.
- Follow-Ups:
- Re: "Talking" to a "busy" application
- From: cassiope
- Re: "Talking" to a "busy" application
- Prev by Date: 2nd call IS 2012 (Berlin, Germany) – submissions until 30 December 2011
- Next by Date: Re: FAT16 boot record error
- Previous by thread: 2nd call IS 2012 (Berlin, Germany) – submissions until 30 December 2011
- Next by thread: Re: "Talking" to a "busy" application
- Index(es):
Relevant Pages
|