1. Home
  2. Embedded Programming
  3. "Talking" to a "busy" application

"Talking" to a "busy" application

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,

Reply to
Don Y
Loading thread data ...

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 to
cassiope

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).

"I don't do windows."

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

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 to
Don Y

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 to
cassiope

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)

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.

Reply to
Don Y

ElectronDepot website is not affiliated with any of the manufacturers or service providers discussed here. All logos and trade names are the property of their respective owners.