[comp.windows.x] X event handling and signals

PARCEL@INTELLICORP.COM (Scott Parcel) (02/27/90)

I have some questions and comments about the recent discussion of
handling events inside of Unix signal handlers.  My particular
interest is in using signals to do all X event processing.

First, some of the comments imply a problem with interrupts occuring
at all, causing returns from reads etc., some seem to be concerned
with the problems of reentrant execution of Xlib calls.  It was also
suggested that various toolkits can be used to avoid some of these
problems -- which confuses me since the toolkits all make Xlib calls
(I'm missing something - but I'm a novice at X).

The following is my understanding of signal handling problems and
methodology:

    1.  Reentrant execution of any Xlib routines which manipulate the
        event queue can cause protocol errors.  If events are handled
        only inside of a signal handler, hence no reentrant calls to
        Xlib, there should be no Xlib problem.

    2.  Reentrant execution of some Unix system calls can be a
        problem, independant of the use of X.  Globals like errno are
        easily messed up.  I don't yet know exactly which system calls
        to be concerned about, or the best way to protect onesself.

    3.  Interupts can cause system calls to return with an error,
        independant of the use of X.  Your code needs to expect this.
        I don't know how X copes with this.  We do most of our X code
        inside of interupts, we do not alloww signals to interupt Xlib
        code.

    4.  If signals are the primary means of processing events, some
        mechanism must be used to watch for the X timers - a little
        invasive since the timer queue is not a "public" part of X.

    5.  Xt can handle reentrant execution of XtDispatchEvent(), but as
        before, if a callback fired by XtDispatchEvent() happens to be
        doing any Xlib calls reentrant execution of Xlib must be
        avoided.  (For some reason unknown to me, timer callbacks in
        Xt are not managed in the same reentrant fashion as
        XtDispatchEvent, consequently destroys occuring inside of a
        timer callback inside of XtAppProcessEvent() inside of
        XtDispatchEvent() are put on the earlier XtDispatchEvent
        destroy queue.)

Questions:

    0.  Am I correct in assuming the problems with reentrant execution
        of Xlib calls have to do with operations which read or write
        to the event queues ?

    1.  Are there reentrancy problems in Xt itself ?

    2.  Is there a good workaround to detect interuption of
        nonreentrant system calls or deal with reentrant execution of
        system calls ?

    3.  How does XView 'notify_do_dispatch' handle this stuff ?

    4.  Why are timer callbacks in Xt not handled in a manner similar
        to XtDispatchEvent ? 

    5.  How do the toolkits handle signals more gracefully than Xlib
        alone ?

-- scott parcel   parcel@intellicorp.com


-------