Path: utzoo!utgpu!jarvis.csri.toronto.edu!rutgers!cs.utexas.edu!swrinde!ucsd!ucbvax!decwrl!crltrx!max.crl.dec.com!jg
From: jg@max.crl.dec.com (Jim Gettys)
Newsgroups: comp.windows.x
Subject: Re: X & signals
Keywords: xwindows signals
Message-ID: <4663@crltrx.crl.dec.com>
Date: 24 Feb 90 18:51:00 GMT
References: <1154@sdrc.UUCP> <132200@sun.Eng.Sun.COM>
Sender: news@crltrx.crl.dec.com
Reply-To: jg@max.crl.dec.com (Jim Gettys)
Organization: DEC Cambridge Research Lab
Lines: 59

In article <132200@sun.Eng.Sun.COM> argv@sun.UUCP (Dan Heller) writes:

> 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's ships circa 1492 and
> VMS does not support signals....

As the person who did Xlib, as well as the "strong Digital involvement",
I care to set the record straight.  I have been using Unix off and on
since 1976; while I have VMS experience, it entirely predates Digital,
and was for 3 of those 14 years; my Unix usage is more like 9 of those
years, and the entire time I've been at Digital.  Don't impune someone's
motives without good cause. 

And speaking of Columbus, Unix is older than VMS. :-).  It also deals
with asynchronous stuff much better than Unix.  The reason why Xlib
ducks is that Unix hasn't been up to it.  (Don't take me for a VMS lover
though; I'm emphatically not fond of it personally.)

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.

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.

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.

4) the only issue with Xlib and signals is that you had better not call
back into Xlib ON THE SAME CONNECTION to a server from a signal handler.
On systems that allow system call restart, the implementation should be
doing the right thing.

If you've ever looked at Xlib sources, you would have seem that in fact
there has been some provision for locking of Xlib data structures.  Some
people's Xlib implementations on some operating systems may in fact work
correctly (i.e. allow calling into Xlib from a signal handler).  At the
time I was working on the X11 Xlib, I had a 5 processor SMP workstation
in my office (DECSRC Firefly running Topaz,
a research system capable of running Unix binaries, but with threads and
very fast RPC), so don't accuse me of ignorance.  There was also some
care put into the interface design for multi-processing; contrast this
to Unix's use of errno.

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.  Closest things to decent right now are
DECSRC's Topaz and CMU's Mach.  In the meanwhile, Xlib will be silent on
the issue, rather than doing what could be at best a half-assed job
which would just get us into trouble when POSIX threads finally become
a reality.  Even then, we've got mucho trouble just with the Unix
system call interface, for example.
				- Jim Gettys