XtAppAddTimeOut question - Motif

This is a discussion on XtAppAddTimeOut question - Motif ; Hello, I have a question about the implementation of XtAppAddTimeOut(). Exactly when and how does my timer callback routine get called from XtAppMainLoop()? Is this called via a signal handler that will possibly interrupt some other piece of my code ...

+ Reply to Thread
Results 1 to 10 of 10

Thread: XtAppAddTimeOut question

  1. XtAppAddTimeOut question

    Hello,

    I have a question about the implementation of XtAppAddTimeOut().
    Exactly when and how does my timer callback routine get called from
    XtAppMainLoop()? Is this called via a signal handler that will
    possibly interrupt some other piece of my code which may be
    executing at the time, e.g., another callback routine that is
    dealing with user-initiated GUI activity? Or, is it called from
    some safe place in XtAppMainLoop() where it is guaranteed that
    no other callback of mine will be interrupted?

    My app is monitoring a real-time data feed. I originally
    coded it to poll this data feed using a work procedure,
    but that seems to crank the CPU utilization up to
    nearly 100%. The timer callback appears to work much better
    in this regard but I am concerned about the interrupt issue.

    Thanks!

    Roger Davis
    rbd@NOSPAM.hawaii.edu

  2. Re: XtAppAddTimeOut question

    rbd@planet10.soest.hawaii.edu (Roger Davis) wrote in news:d2hh3a$jgg$1
    @news.hawaii.edu:
    > I have a question about the implementation of XtAppAddTimeOut().
    > Exactly when and how does my timer callback routine get called from
    > XtAppMainLoop()?


    On most systems, Xt timers are handled by setting the select() timeout within
    the main loop.

    Ken Lee, http://www.rahul.net/kenton/

  3. Re: XtAppAddTimeOut question

    In article ,
    Ken writes:

    >> I have a question about the implementation of XtAppAddTimeOut().
    >> Exactly when and how does my timer callback routine get called from
    >> XtAppMainLoop()?

    >
    > On most systems, Xt timers are handled by setting the select() timeout within
    > the main loop.
    >
    > Ken Lee, http://www.rahul.net/kenton/


    Thank you, Ken. So, this means that there are no signal interrupt routines
    involved, and I can assume that none of my other Xt callback procedures
    will ever be interrupted by the timer callback that I registered with
    XtAppAddTimeout()?

    Roger

  4. Re: XtAppAddTimeOut question

    Hi Roger,

    > I have a question about the implementation of XtAppAddTimeOut().


    Have you examined the source of it?

    > Exactly when and how does my timer callback routine get called from
    > XtAppMainLoop()? Is this called via a signal handler that will
    > possibly interrupt some other piece of my code which may be executing
    > at the time, e.g., another callback routine that is dealing with
    > user-initiated GUI activity?


    No pre-emption occurs. If your callback handling a button press
    sleep(3)s for 60 seconds then no events get handled, no workprocs
    called, etc.

    > Or, is it called from some safe place in XtAppMainLoop() where it is
    > guaranteed that no other callback of mine will be interrupted?


    Think of it as just like a callback, except one that occurs when a
    minimum amount of time has passed. You don't expect your ButtonPressed
    callback to be interrupted by another call to it if the user clicks
    quickly, do you?

    > My app is monitoring a real-time data feed. I originally coded it to
    > poll this data feed using a work procedure, but that seems to crank
    > the CPU utilization up to nearly 100%.


    Yes, have you found a Fine Manual to peruse? A workproc is called
    whenever there's some spare CPU time; that's its raison d'etre.

    > The timer callback appears to work much better in this regard but I am
    > concerned about the interrupt issue.


    It's better, but what form does this real-time data feed take? I'd have
    thought you want XtAppAddInput(3) so Xt adds the file descriptor to the
    select(2).

    Cheers,

    --
    Ralph Corderoy. http://inputplus.co.uk/ralph/ http://troff.org/

  5. Re: XtAppAddTimeOut question

    Ralph Corderoy wrote:

    > Yes, have you found a Fine Manual to peruse? A workproc is called
    > whenever there's some spare CPU time; that's its raison d'etre.


    Would it be more accurate to state that a workproc is requeued to the
    end of the even queue queued everytime it completes ?

    Is there the concept of priority in event queues where say, a keypress
    would generate an event that gets processed before a workproc even if it
    arrived after the workproc was re-queued ?

    Or are events executed on a firsts come first served basis ?

  6. Re: XtAppAddTimeOut question

    In article <1112562570.ae81dfb291d71c67fc559eb2f16502ac@terane ws> JF Mezei writes:
    >Ralph Corderoy wrote:


    >> Yes, have you found a Fine Manual to peruse? A workproc is called
    >> whenever there's some spare CPU time; that's its raison d'etre.


    >Would it be more accurate to state that a workproc is requeued to the
    >end of the even queue queued everytime it completes ?


    More accurate to say that the workproc gets called whenever there are no
    events in the event queue to process.

    At least that's what I remember from when I looked at the event loop code.

    -Pete Zakel
    (phz@seeheader.nospam)

    "Another Glitch In The Call"
    (sung to the tune of a recent Pink Floyd hit)

    We don't need no indirection
    We don't need no flow control
    No data typing or declarations
    Did you leave the lists alone?

    Hey! Hacker! Leave those lists alone!

    Chorus:
    All in all, it's just a pure-LISP function call...
    All in all, it's just a pure-LISP function call...

  7. Re: XtAppAddTimeOut question

    Hi JF,

    > > Yes, have you found a Fine Manual to peruse? A workproc is called
    > > whenever there's some spare CPU time; that's its raison d'etre.

    >
    > Would it be more accurate to state that a workproc is requeued to the
    > end of the even queue queued everytime it completes ?


    No. The workproc doesn't sit as a `false event' in the event queue
    waiting its turn to be processed.

    > Is there the concept of priority in event queues where say, a keypress
    > would generate an event that gets processed before a workproc even if
    > it arrived after the workproc was re-queued ?


    The workproc is considered separately from the event queue. While
    events are sitting waiting to be processed, they're processed. If
    there's no events then rather than block waiting for more to arrive the
    workproc is called. That's why CPU usage hits 100%: instead of the
    loop being a non-busy one with the process sleeping until events arrive
    it becomes busy calling the workproc repeatedly instead of sleeping. A
    workproc is intended to get a finite task done in bite-sized chunks, not
    to poll an external event source.

    > Or are events executed on a firsts come first served basis ?


    Yes, the X protocol is asynchronous, not out of order.

    Cheers,

    --
    Ralph Corderoy. http://inputplus.co.uk/ralph/ http://troff.org/

  8. Re: XtAppAddTimeOut question

    Ralph Corderoy wrote:
    > The workproc is considered separately from the event queue.


    Ok thanks.

    So essentially there are 2 queues checked by the event loop:

    the event queue (which is checked first) and a workproc queue which is
    only checked when the event queue is empty.

    In essence this gives events a higher priority than workprocs.

  9. Re: XtAppAddTimeOut question

    Hi JF,

    > > The workproc is considered separately from the event queue.

    >
    > Ok thanks. So essentially there are 2 queues checked by the event
    > loop:
    >
    > the event queue (which is checked first) and a workproc queue which is
    > only checked when the event queue is empty.
    >
    > In essence this gives events a higher priority than workprocs.


    Yes, but if a workproc takes 10 seconds to do its work then events
    aren't processed in the meantime; there's no pre-emption.

    And then there's timer callbacks. UTSL, it isn't that opaque.

    Cheers,

    --
    Ralph Corderoy. http://inputplus.co.uk/ralph/ http://troff.org/

  10. Re: XtAppAddTimeOut question



    Ralph Corderoy wrote:
    >
    > Hi JF,
    >
    > > > The workproc is considered separately from the event queue.

    > >
    > > Ok thanks. So essentially there are 2 queues checked by the event
    > > loop:
    > >
    > > the event queue (which is checked first) and a workproc queue which is
    > > only checked when the event queue is empty.
    > >
    > > In essence this gives events a higher priority than workprocs.

    >
    > Yes, but if a workproc takes 10 seconds to do its work then events
    > aren't processed in the meantime; there's no pre-emption.
    >
    > And then there's timer callbacks. UTSL, it isn't that opaque.
    >
    > Cheers,
    >
    > --
    > Ralph Corderoy. http://inputplus.co.uk/ralph/ http://troff.org/


    XtAppMainLoop() looks like this:

    for (; {
    XtAppNextEvent(app, &event);
    XtDispatchEvent(&event);
    }

    The check for timers, events, and workprocs is done in XtAppNextEvent().
    That function first invokes all expired timeouts. Then it checks to see
    whether there is an event on the event queue; if one exists, it extracts
    that event and returns it. If there are no events, it checks for
    workprocs and, if they exist, invokes the next one, then loops back to
    the beginning to check for timers, etc.
    --
    Fred L. Kleinschmidt
    Boeing Associate Technical Fellow
    Technical Architect, Common User Interface Services
    M/S 2R-94 (206)544-5225

+ Reply to Thread