🚀 go-pugleaf

In article <4429@quanta.eng.ohio-state.edu> JONESD@kcgl1.eng.ohio-state.edu (David Jones) writes:
> Instead of hacking up tookits to allow your application to add signal handlers,
> I'd rather see them hacked up to convert signals into client events.  The
> application would deal with with the signal as another event to deal and
> not as something to be dealt with by a signal handler.

That's fundamentally the same thing I'm talking about.  That is,
you register signals and handlers (functions) associated with those
signals in case a signal is delivered.  The toolkit then calls the
function registered.  However, the idea asbout converting signals
into events odesn't make sense -- signals don't happen in windows [%]
and they don't have x,y values or serial IDs etc.. associated with
them so the generic event type can't fill in anything.  Keep the
signals as signals...

[%] SIGWINCH is a possible exception and an interesting case..
altho not that interesting...

    From: PARCEL@INTELLICORP.COM (Scott Parcel)
    Subject: X & Signals
    Message-ID: <9002281442.aa11275@mintaka.lcs.mit.edu>
    Date: 28 Feb 90 19:37:02 GMT

    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?

The following is my understanding of signal handling problems and
methodology:
dan
-----------------------------------------------------------
		    O'Reilly && Associates
		argv@sun.com / argv@ora.com
	   632 Petaluma Ave, Sebastopol, CA 95472 
     800-338-NUTS, in CA: 800-533-NUTS, FAX 707-829-0104
    Opinions expressed reflect those of the author only.