Path: utzoo!attcan!uunet!cs.utexas.edu!usc!venera.isi.edu!raveling
From: raveling@isi.edu (Paul Raveling)
Newsgroups: comp.windows.x
Subject: Re: X & signals
Keywords: xwindows signals
Message-ID: <12058@venera.isi.edu>
Date: 27 Feb 90 19:53:57 GMT
References: <1154@sdrc.UUCP> <132200@sun.Eng.Sun.COM>
Sender: news@venera.isi.edu
Reply-To: raveling@isi.edu (Paul Raveling)
Organization: USC Information Sciences Institute
Lines: 37

In article <132200@sun.Eng.Sun.COM>, argv%turnpike@Sun.COM (Dan Heller) writes:
> In article <1154@sdrc.UUCP> evgabb@sdrc.UUCP (Rob Gabbard) writes:
>> 
> Stop right there.  don't event *think* about using signals with X
> in its current state.  ...
> The problem is that Xlib has no layer for signal handling.

	No, the real problem is that UNIX signals are utterly
	inadequate and inappropriate.

	For the record, it took me about 2 orders of magnitude
	too much development time to get the signaling in the
	Img Software Set's "exhibit" program to work without
	race condition problems.  This should have been trivial.

	This among other reasons is why I've begun seriously
	proposing an OS project to supply a good kernel to slip
	"under" UNIX.  If you like, you can consider this as a
	grandchild of the EPOS system that we did in 1975 -- it
	was one of a family that demonstrated a way to do this
	sort of synchronization & IPC that was

	    --  Easy to use
	    --  Reliable (not prone to UNIXish race conditions)
	    --  Much faster than UNIX
	    --  Versatile (solved lots of other problems as well --
		We used it for "process-oriented programming", which
		was a bit like object-oriented programming with 1
		process per object.

	Is anyone out there willing to sponsor a "next generation"
	variant of this?


----------------
Paul Raveling
Raveling@isi.edu