🚀 go-pugleaf

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

>Can you please explain this?  This makes no sense to me.
>What kind of interface do you provide for an application
>that does nothing but trap signals?  What kind of functionality
>does such an application serve?

Our need to process events within a signal handler comes from the following
constaints:
   1.  Arbitrary, mostly unconstrained and uncooperative code may be running
       within the same process as our X code.  
   2.  We want to handle any x events that occur even while this arbitrary
       code is running.
   3.  We do not believe that it is practical to separate our X code into
       a separate process.
I know this is considered a bad idea, however I am very familiar with writing
event driven code and multiprocess applications and it does not appear that
these solutions will do the trick this time.  I am presently looking into
how to detect having interupted nonreentrant system library calls.
-- scott  "I know its stupid, but I gotta do it" parcel@intellicorp.com

By the way .. I have this working pretty well  -- but I want to cover all
the bases.
-- scott
-------