evgabb@sdrc.UUCP (Rob Gabbard) (02/23/90)
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:
clean_queue()
{
while ( XPending( display ) )
{
XtNextEvent( &event );
XtDispatchEvent( &event );
}
signal(SIGALRM,clean_queue);
}
Upon exiting my event loop to go and do something else I call
signal(SIGALRM,clean_queue) and then use setitimer to send an alarm every
few seconds. Then, when reentering my event loop I turn the timer back off.
This works fine for a while but it eventually crashes. The error
messages range from invalid protocol requests to bad op codes in
XDeleteProperty. This is running under Ultrix on a DECStation 3100.
--
________ _________ _______ ________
/ _______| | ____ \ | ___ \ / _______|
Rob Gabbard (uunet!sdrc!evgabb) | |______ | | \ \ | | \ | | /
Technical Development Engineer \_______ \ | | | | | |___/ / | |
Structural Dynamics Research Corp. ______| | | |____/ / | ____ \ | \_______
#include <std/disclaimer.h> |________/ |________/ |_| |_| \________|argv%turnpike@Sun.COM (Dan Heller) (02/24/90)
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
asente@decwrl.dec.com (Paul Asente) (02/24/90)
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' ships circa 1492) and >VMS does not support signals... That's a pretty dubious explanation. Try 1) Xlib version 11 is still rather similar internally to Xlib version 10, which DEC had nothing to do with, and which didn't support signals either. 2) The developers of X11 had a huge amount of stuff on their plates as it was, and putting signal handling in Xlib was one of the 143 things they would have liked to have done but didn't have time for. Anyway, VMS has asynchronous events that are rather similar to signals, and the VMS Xlib handles them just fine (its internal layers are different from the Unix internal layers, not surprisingly). >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(). -paul asente asente@decwrl.dec.com decwrl!asente
rws@EXPO.LCS.MIT.EDU (Bob Scheifler) (02/25/90)
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.jg@max.crl.dec.com (Jim Gettys) (02/25/90)
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
argv%turnpike@Sun.COM (Dan Heller) (02/25/90)
> 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
jg@max.crl.dec.com (Jim Gettys) (02/25/90)
Of course, some of us might actually not think threads are all that far off; there are many implementations around, and have been for years. I mean, by the time standards committees (like POSIX) in this case get in the act, as they are today, things are way down stream.... I am very much opposed to crufting up libraries to cover up Unix's faults. And I don't believe threads are so far in the future that it is worth the cruft. - Jim
moraes@cs.toronto.edu (Mark Moraes) (02/26/90)
As has often been pointed out before (comp.lang.c, comp.std.c, comp.std.unix) about the only thing one can do safely in a signal handler is set a flag, and return, or cleanup and exit. (Even the latter may not be quite safe, but heck, you're exiting...) Calling any procedure or touching global data is perilous -- parts of the C library are not reentrant (malloc for sure) and calling anything that might call these parts might put your application into a very confused state. I don't know how much of Xlib or Xt is re-entrant, I suspect there are non-re-entrant parts. (Perhaps a scenario where Xlib gets interrupted when packing data into a buffer, the signal handler tries to pack more data into that buffer resulting in an interleaved mess?)
gjc@mitech.com (02/26/90)
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: >> Has anyone had any problems with using alarm signals with X ? My problem is > > Stop right there. don't event *think* about using signals with X > in its current state. If you do, then think *really hard* because > VMS does not support signals... > > ----------------------------------------------------------- > O'Reilly && Associates > argv@sun.com / argv@ora.com What rubbish, and from somebody at a place that publishes books about X. (Or maybe your complete message was just a joke?) The VMS implementation of XLIB could very well be the ONLY implementation that supports ASYNC operation. The XLIB routines are reentrant and can be called at AST level, and there is even a routine XSelectAsyncInput(display,window,mask,event_ast_handler,ast_arg) which will interrupt your process when pending X-events come into the queue. VMS not handling signals? On the contrary, XLIB seems to have been designed with the least-common-denominator of least-able operating systems in mind when it comes to processing input (including clock driven). Indeed, the nature of it is such that X (applications/server) can run in operating systems such as the Macintosh, where the operating system has to be called explicitely from the application, e.g. "SystemTask()" in order to process user input properly. If DIGITAL had really managed to get the X Constortium to write X in such a way that it depended on the superior I/O/timing capabilities of VMS, then X would have great difficulting running on other platforms. That would not be in the best interest of DIGITAL, and X would not now be as important as it is. -gjc p.s. Here is what I have to do on the Mac in order to look for the key that a user conventionally types to interrupt a running program. It would be nice to have more event-queue (in a general sense) procedures such as in X. This kind of stuff even makes Unix look good. int want_interrupt() {SystemTask(); for(q=EventQueue.qHead;q;q=q->qLink) if(q->evtQWhat == keydown && (char) q->evtQmessage == '.' && (q->evtQModifiers && cmdKey)) return(1); return(0);}
tml@hemuli.tik.vtt.fi (Tor Lillqvist) (02/27/90)
An example that is't bad to use signals in X programs is xfig-2.0. At least on HP-UX, it dumps core unless you #ifdef out the calls to setitimer in blink.c. (Xfig uses interval timers to make a blinking cursor.) -- Tor Lillqvist, working, but not speaking, for the Technical Research Centre of Finland
envbvs@epb2.lbl.gov (Brian V. Smith) (02/27/90)
In article <4559@hemuli.tik.vtt.fi>, tml@hemuli.tik.vtt.fi (Tor Lillqvist) writes: > An example that is't bad to use signals in X programs is xfig-2.0. At > least on HP-UX, it dumps core unless you #ifdef out the calls to > setitimer in blink.c. (Xfig uses interval timers to make a blinking > cursor.) xfig has used setitimer() to blink the cursor since at least version 1.4.3. If someone has a better way to do it, I would appreciate the input. _____________________________________ Brian V. Smith (bvsmith@lbl.gov) Lawrence Berkeley Laboratory I don't speak for LBL, these non-opinions are all mine.
tml@hemuli.tik.vtt.fi (Tor Lillqvist) (02/27/90)
In article <4956@helios.ee.lbl.gov> envbvs@epb2.lbl.gov (Brian V. Smith) writes: >In article <4559@hemuli.tik.vtt.fi> I write: >> An example that is't bad to use signals in X programs is xfig-2.0. At >xfig has used setitimer() to blink the cursor since at least version 1.4.3. Sorry, I didn't mean to point the finger at xfig _2.0_, I had to rip the blinking out of xfig 1.4, too. >If someone has a better way to do it, I would appreciate the input. Don't do it? -- Tor Lillqvist, working, but not speaking, for the Technical Research Centre of Finland
raveling@isi.edu (Paul Raveling) (02/28/90)
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
erik@sravd.sra.JUNET (Erik M. van der Poel) (02/28/90)
In article <4956@helios.ee.lbl.gov> Brian V. Smith writes: > >xfig has used setitimer() to blink the cursor since at least version 1.4.3. >If someone has a better way to do it, I would appreciate the input. XtAppAddTimeOut() Erik M. van der Poel erik@sra.co.jp (Japan) SRA, 1-1-1 Hirakawa-cho, Chiyoda-ku erik%sra.co.jp@uunet.uu.net (USA) Tokyo 102 Japan. TEL +81-3-234-2692 erik%sra.co.jp@mcvax.uucp (Europe)
rws@EXPO.LCS.MIT.EDU (Bob Scheifler) (02/28/90)
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).
Xt and Xlib interfaces are generally designed to be OS independent. I don't
know if a "generic" design is possible here (that may be part of the problem).
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.
I don't think I've ever seen a good exposition of the "problem with signals",
and what the application requirements really are. I don't know if there's
consensus on the requirements. Not knowing VMS ASTs, I don't know how the
requirements match those for VMS programmers. Without a reasonable set of
requirements, it's hard to propose or evaluate a mechanism.
By your signature line, you work for a member of the X Consortium. The
X Consortium doesn't do things by magic, it takes people willing to do work.
I haven't seen many people in the Consortium express concern about this issue,
but that doesn't mean they wouldn't be willing to adopt something if someone
was willing to do the work. Perhaps you'd like to write up what the issues
are, propose a design, write it up, supply a sample implementation, and help
the X Consortium solve the "problem with signals".PARCEL@INTELLICORP.COM (Scott Parcel) (03/01/90)
I have some questions and comments about the recent discussion of
handling events inside of Unix signal handlers. My particular
interest is in using signals to do all X event processing.
First, some of the comments imply a problem with interrupts occuring
at all, causing returns from reads etc., some seem to be concerned
with the problems of reentrant execution of Xlib calls. It was also
suggested that various toolkits can be used to avoid some of these
problems -- which confuses me since the toolkits all make Xlib calls
(I'm missing something - but I'm a novice at X).
The following is my understanding of signal handling problems and
methodology:
1. Reentrant execution of any Xlib routines which manipulate the
event queue can cause protocol errors. If events are handled
only inside of a signal handler, hence no reentrant calls to
Xlib, there should be no Xlib problem.
2. Reentrant execution of some Unix system calls can be a
problem, independant of the use of X. Globals like errno are
easily messed up. I don't yet know exactly which system calls
to be concerned about, or the best way to protect onesself.
3. Interupts can cause system calls to return with an error,
independant of the use of X. Your code needs to expect this.
I don't know how X copes with this. We do most of our X code
inside of interupts, we do not alloww signals to interupt Xlib
code.
4. If signals are the primary means of processing events, some
mechanism must be used to watch for the X timers - a little
invasive since the timer queue is not a "public" part of X.
5. Xt can handle reentrant execution of XtDispatchEvent(), but as
before, if a callback fired by XtDispatchEvent() happens to be
doing any Xlib calls reentrant execution of Xlib must be
avoided. (For some reason unknown to me, timer callbacks in
Xt are not managed in the same reentrant fashion as
XtDispatchEvent, consequently destroys occuring inside of a
timer callback inside of XtAppProcessEvent() inside of
XtDispatchEvent() are put on the earlier XtDispatchEvent
destroy queue.)
Questions:
0. Am I correct in assuming the problems with reentrant execution
of Xlib calls have to do with operations which read or write
to the event queues ?
1. Are there reentrancy problems in Xt itself ?
2. Is there a good workaround to detect interuption of
nonreentrant system calls or deal with reentrant execution of
system calls ?
3. How does XView 'notify_do_dispatch' handle this stuff ?
4. Why are timer callbacks in Xt not handled in a manner similar
to XtDispatchEvent ?
5. How do the toolkits handle signals more gracefully than Xlib
alone ?
-- scott parcel parcel@intellicorp.com
-------casey@gauss.llnl.gov (Casey Leedom) (03/02/90)
| From: raveling@isi.edu (Paul Raveling) | | 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. Which version of UNIX are you talking about? Even System V has reliable signals these days (albeit 4.1BSD signals). If you're having race condition problems on any modern UNIX, they're in your code, not the OS. I will admit that the 4.1BSD signal facility found in System V is uglier than mud and extremely difficult to use for complex interaction with multiple signals. The signal facility that was introduced with 4.2BSD is *MUCH* nicer. I will never understand why AT&T went with the 4.1BSD signal facility when they finally decided to put reliable signals into System V. I can only guess severe and total brain damage. Casey
PARCEL@INTELLICORP.COM (Scott Parcel) (03/06/90)
> I have some questions and comments about the recent discussion of > handling events inside of Unix signal handlers. My particular > interest is in using signals to do all X event processing. >Can you please explain this? This makes no sense to me. >What kind of interface do you provide for an application >that does nothing but trap signals? What kind of functionality >does such an application serve? Our need to process events within a signal handler comes from the following constaints: 1. Arbitrary, mostly unconstrained and uncooperative code may be running within the same process as our X code. 2. We want to handle any x events that occur even while this arbitrary code is running. 3. We do not believe that it is practical to separate our X code into a separate process. I know this is considered a bad idea, however I am very familiar with writing event driven code and multiprocess applications and it does not appear that these solutions will do the trick this time. I am presently looking into how to detect having interupted nonreentrant system library calls. -- scott "I know its stupid, but I gotta do it" parcel@intellicorp.com By the way .. I have this working pretty well -- but I want to cover all the bases. -- scott -------
hvr@kimba.Sun.COM (Heather Rose) (03/07/90)
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: > > clean_queue() > { > while ( XPending( display ) ) > { > XtNextEvent( &event ); > XtDispatchEvent( &event ); > } > > signal(SIGALRM,clean_queue); > } > > Upon exiting my event loop to go and do something else I call >signal(SIGALRM,clean_queue) and then use setitimer to send an alarm every >few seconds. Then, when reentering my event loop I turn the timer back off. > > This works fine for a while but it eventually crashes. The error >messages range from invalid protocol requests to bad op codes in >XDeleteProperty. This is running under Ultrix on a DECStation 3100. The XView toolkit provides an interface for signals (including alarms). If you are not using XView, you might want to take a peek at the implementation of the notifier library. XView source is included in the X11R4 distribution. The applicable code would be in <contrib>/toolkits/XView/lib/libxvin/notify Regards, Heather
hvr@kimba.Sun.COM (Heather Rose) (03/07/90)
In article <2888@bacchus.dec.com> asente@decwrl.dec.com (Paul Asente) writes: >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' ships circa 1492) and >>VMS does not support signals... > >That's a pretty dubious explanation. Try >1) Xlib version 11 is still rather similar internally to Xlib version 10, >which DEC had nothing to do with, and which didn't support signals either. >2) The developers of X11 had a huge amount of stuff on their plates as >it was, and putting signal handling in Xlib was one of the 143 things they >would have liked to have done but didn't have time for. This is very true...as anyone who has looked at the XView notifier code will tell you ;-) Regards, Heather
hvr@kimba.Sun.COM (Heather Rose) (03/10/90)
In article <9003052147.AA25962@expo.lcs.mit.edu> PARCEL@INTELLICORP.COM (Scott Parcel) writes: > >Our need to process events within a signal handler comes from the following >constaints: > 1. Arbitrary, mostly unconstrained and uncooperative code may be running > within the same process as our X code. > 2. We want to handle any x events that occur even while this arbitrary > code is running. > 3. We do not believe that it is practical to separate our X code into > a separate process. >I know this is considered a bad idea, however I am very familiar with writing >event driven code and multiprocess applications and it does not appear that >these solutions will do the trick this time. I am presently looking into >how to detect having interupted nonreentrant system library calls. Take a look at the XView notify code. It sounds to me that this is just what you're looking for. <X11R4>/contrib/toolkits/XView/lib/libxvin/notify. Regards, Heather