Path: utzoo!utgpu!jarvis.csri.toronto.edu!cs.utexas.edu!tut.cis.ohio-state.edu!ucbvax!bloom-beacon!INTELLICORP.COM!PARCEL
From: PARCEL@INTELLICORP.COM (Scott Parcel)
Newsgroups: comp.windows.x
Subject: X & Signals
Message-ID: <9003052147.AA25962@expo.lcs.mit.edu>
Date: 5 Mar 90 21:49:21 GMT
Sender: daemon@athena.mit.edu (Mr Background)
Organization: The Internet
Lines: 27

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