🚀 go-pugleaf

In article <1154@sdrc.UUCP> evgabb@sdrc.UUCP (Rob Gabbard) writes:
> Has anyone had any problems with using alarm signals with X ? My problem is
> this - I have an X application that may be away from the event loop for 
> quite some time.  So, to avoid overflowing the event queue, I have a routine
> that looks somthing like this:

Stop right there.  don't event *think* about using signals with X
in its current state.  If you do, then think *really hard* because
there are several things to consider.  The most important is the
interruption of the protocol between the X server and the client.
Due to its asynchronous nature, an event may not be delivered when
you might think and if a signal is delivered, you will surely die
with an array of unpredictable errors especially if you attempt
any communication with the server in any way.

The problem is that Xlib has no layer for signal handling.  The
reason is dubious, but it's in many people's opinion that it's
due to DEC's strong involvement with X and since DEC really likes
VMS (brought to the US on one of Columbus' ships circa 1492) and
VMS does not support signals...

Solutions: (in order of likelihood)

1)  Avoid using Xlib as the main interface layer to your application.
    Use a toolkit of some kind.  Xt provides for a timer that handles
    SIGALARM, but that's the only signal it provides for.  If you want
    to handle other signals, see some of the notes below.  Note, you
    don't have to avoid using Xt because it doesn't handle other
    signals, you just have to be careful.

    The XView toolkit provides for UNIX signals very well.  In fact,
    it is the only toolkit I know of that does.  however, Xview is
    not a general purpose toolkit and does not allow you to build
    generic user interfaces.  However, the part of XView that does
    signal handling is part of the Notifier, which is not bound to
    XView's interface layer.  That is, you can use the Notifier to
    do signal handling and other nice features without actually
    building Xview (open look) objects.  That is, you could build
    upon your Xlib layer and use the Notifier if you want.  You should
    see the XView Programmer's Manual (Volume 7 O'Reilly series on
    X programming) for info on this.

2)  Check your event queue and only call signal handlers when it is
    *safe* to do so.  That means that you should catch signals
    internally in your program and note the fact that the signal
    has been delivered.  At the top of your event processing loop,
    flush the event queues and then call the signal handler you
    -really- want to have handle the signal.

    Note: this is not a trivial thing to do so be very careful.
    It can appear to work correctly even tho it doesn't in the
    general case.  A great deal of experiementation is necessary.
    Since XView is free, you should check the Notifier code and
    utilize ideas drawn from that work.  Don't copy it. :-)

3)  Sue Donald Trump for the $20M that Ivana doesn't want.

4)  Put pressure on The X consortium to consider signal handling
    more importantly than the attention it is currently being given.
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