Path: utzoo!utgpu!jarvis.csri.toronto.edu!cs.utexas.edu!mailrus!ames!sun-barr!newstop!sun!turnpike!argv From: argv%turnpike@Sun.COM (Dan Heller) Newsgroups: comp.windows.x Subject: Re: X & signals Keywords: xwindows signals Message-ID: <132219@sun.Eng.Sun.COM> Date: 24 Feb 90 20:48:01 GMT References: <1154@sdrc.UUCP> <132200@sun.Eng.Sun.COM> <4663@crltrx.crl.dec.com> Sender: news@sun.Eng.Sun.COM Reply-To: argv@sun.UUCP (Dan Heller) Lines: 105 > 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