🚀 go-pugleaf

>    From: rws@EXPO.LCS.MIT.EDU (Bob Scheifler)
>    Newsgroups: comp.windows.x
> >  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...
> This is one of the more stupid statements I've seen on xpert in recent times.

I seem to have upset a number of people with this.  Had I not
found it so amusing when someone from DEC made this statement
to me, I probably wouldn't have included it here.  At any rate,
sorry for having ruffled feathers...

>    From: asente@decwrl.dec.com (Paul Asente)
>    Organization: DEC Western Software Lab
> >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.
> The Xt timers are not asynchronous; they just manipulate the time values
> sent to select().

Sorry for the confusion. I should have stated that Xt "mimics" the
signal SIGARLM with its use of XtAddTimeOut().  It doesn't really
use SIGARLM as I seem to suggest.

I think Jim Gettys has offered the most thoughtful and informative
response so far.

>   From: jg@max.crl.dec.com (Jim Gettys)
>   Organization: DEC Cambridge Research Lab
> 1) Xlib cannot AFFORD to mess with signals in the default case (i.e.
> protect the X buffer and/or event queue by masking signals).  The system
> call overhead is much too high.  Other approaches are possible
> given locking of Xlib data structures.

This comes up again later, but is a reasonable statement: There are
other mechanisms that make it possible to prevent protocol corruptions
that can occur from the signal handler trying to call Xlib routines.
Thus, I submit that UNIX applications should not attempt to write
applications that use straightforward Xlib calls without the aid of
a toolkit (especially one that does not do proper signal handling) unless:

1)  you make sure that your signal handlers do not attempt to read
    events, draw to a window or anything else that reequires Xlib.
    For example, someone once asked me about a problem: "I have an
    application that does math computations based on user input
    and I can't determine if there is going to be a division by
    0 unless it happens; I want to trap SIGFPE and put up a dialog
    box indicating the error."  In this case, don't put up a dialog
    box; just note the error and put one up when you reach the top
    of your main event handling loop.
2)  you make sure that events are flushed with the server and
    that your queue is empty and you've handled other events
    on an as-needed basis all within an signal handler.

> 2) Non-BSD based systems have not had "safe signals" (This seems finally
> to be changing).  To presume a given signal model would have reduced
> Xlib's portability greatly.  On most System V based systems, it would
> not have been possible at all.

I've found that #ifdef's suffice.  Specifically (you mention later
"system call restart"), on SYSV, read() returns an error (interrupted
system call) when the signal handler returns.  On BSD, the read()
and other system calls "restart" or pick up where they left off
without returning the error.  Using #ifdef's to determine which type
of system you're on gives you the ability to track for an interrupted
system call and attempt to recover elegantly.  Granted, this doesn't
belong in Xlib, as you state:

> 3) anything Xlib does would almost certainly get in the way of what a
> toolkit would do in this area.  Ergo, Xlib stays out of the way, and
> doesn't do anything to you.

This is the best point made thus far and I agree.  However, because
I agree, I think my response to your point #1 above is more true.
Applications should not use straight Xlib to drive their application.
They should use a toolkit of some kind.  And because of your statement,
I think that the problem of handling signals should be dropped in Xt's
lap.  If Xt is going to be the toolkit "intrinsics", then it should
not leave it to an arbitrary widget set to try to do its own signal
handling.  Perhaps the intrinsics can put signal callback handling in
a "work procedure" somewhere?  Whatever the case, if Xt is going to
handle the lower levels for the real toolkit (widget set), then why
not provide something like XtAddSignalHandler(signal, handler).

> Signals (or VMS AST's) are not the right way to deal with asyncrony, in
> any case; the right solution are threads.  Maybe someday Unix will be a
> decent operating system.

Ok, but what's to be done "now"?  I think that the ideal world/OS is
far enough in the future not to wait for it.  The issue of signals
should be addressed now, even if it's only in documentation.  I would
be happen if the X doc or the consortium gave some sort of recommendation
about what to do with signals rather than avoiding the whole issue.
Better would be an example code (or fragment) that illustrated how
signals should be handled.  The Best solution would be to have Xt deal
with them.
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