1. This forum section is a read-only archive which contains old newsgroup posts. If you wish to post a query, please do so in one of our main forum sections (here). This way you will get a faster, better response from the members on Motherboard Point.

"Talking" to a "busy" application

Discussion in 'Embedded' started by Don Y, Dec 7, 2011.

  1. Don Y

    Don Y Guest

    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
     
    Don Y, Dec 7, 2011
    #1
    1. Advertising

  2. Don Y

    cassiope Guest

    On Dec 7, 6:53 am, Don Y <> 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--
     
    cassiope, Dec 8, 2011
    #2
    1. Advertising

  3. Don Y

    Don Y Guest

    Hi Cassiope,

    On 12/8/2011 1:37 PM, cassiope wrote:
    > On Dec 7, 6:53 am, Don Y<> 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!).
     
    Don Y, Dec 8, 2011
    #3
  4. Don Y

    cassiope Guest

    On Dec 8, 12:49 pm, Don Y <> wrote:
    > Hi Cassiope,
    >
    > On 12/8/2011 1:37 PM, cassiope wrote:
    >
    >
    >
    > > On Dec 7, 6:53 am, Don Y<>  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.
     
    cassiope, Dec 9, 2011
    #4
  5. Don Y

    Don Y Guest

    Hi Cassiope,

    On 12/8/2011 10:09 PM, cassiope wrote:
    > On Dec 8, 12:49 pm, Don Y<> 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.
     
    Don Y, Dec 9, 2011
    #5
    1. Advertising

Want to reply to this thread or ask your own question?

It takes just 2 minutes to sign up (and it's free!). Just click the sign up button to choose a username and then you can ask your own questions on the forum.
Similar Threads
  1. Lurking Rat in 'Da Hood®
    Replies:
    13
    Views:
    609
    Lurking Rat in 'Da Hood®
    Dec 4, 2005
  2. ed sharpe
    Replies:
    1
    Views:
    430
  3. Adam Kumpf

    talking to an RFID chip via wire.

    Adam Kumpf, Jul 23, 2004, in forum: Embedded
    Replies:
    6
    Views:
    386
  4. BF

    People still talking MHZ

    BF, Dec 9, 2003, in forum: AMD Overclocking
    Replies:
    34
    Views:
    646
    Anonymous
    Dec 13, 2003
  5. George Fleagle
    Replies:
    8
    Views:
    260
    Ben Pope
    Jul 6, 2004
Loading...

Share This Page