Article View: comp.windows.x
Article #37693Re: Problem with Signals
From: mitch Mitchel Kuninsky
Date: Mon, 05 Mar 1990 23:19
Date: Mon, 05 Mar 1990 23:19
67 lines
2933 bytes
2933 bytes
argv wrote the following:
>...long description of the problem with X and signals...
>
>Now, you could implement this yourself via "work procs"
>(see XtAddWorkProc()), but the granularity isn't fine enough.
>That is, work procs are only called when there are no events
>pending. Implemented properly, the internals to Xt would
>check in between event delivery to event handlers.
>
>
>dan
Are you suggesting that you do an XtAddWorkProc from the signal
handler? You really can't even do that safely because the client code
being interrupted by the signal might also be in the middle of a call
to XtAddWorkProc and the workproc queue (or whatever database is used
to keep track of them) might be in some inconsistent state. Just about
the ONLY thing you can do safely from a signal handler is set a flag.
One solution to this problem, as you mention in your message, is to set
a flag and use a modified XtMainLoop that checks the flag upon return
from XtNextEvent before calling XtDispatchEvent. I've implemented
something like this and the one problem I have is that the arrival of
the signal will not kick the client out of XtNextEvent so your signal
handler will not get executed until some other event comes along.
Usually, this is no problem, but, if the signal you're catching is
SIGQUIT, there probably will not be any more events coming from the
user.
The real root of this problem, at least on Unix systems, is that the
select in the Xlib tries to recover from being interrupted by a signal
by checking errno for EINTR (which is the value returned when a system
call is interrupted by a signal). If it finds EINTR, it just dives
back into the select call. On the surface, it looks as though you
could hack an Xlib to respond to signals by changing this behaviour so
that XtNextEvent would return with a null event (or something) if it
was interrupted and your special XtMainLoop could examine your signal
flag.
I envision a signal handler like:
SignalHandler
{
sigFlag = TRUE;
}
and an XtMainLoop like:
MyMainLoop()
{
XEvent event;
for (;;)
{
XtNextEvent( &event );
if (event.type != NULL_EVENT) /* or something like this. */
XtDispatchEvent( &event );
if (sigFlag)
{
process signal.
Inhibit signals.
sigFlag = FALSE;
Enable signals.
}
}
}
Technical Details
Message-ID:
<23695@masscomp.ccur.com>Path:
arc1-ca.pugleaf.net!utzoo!utgpu!jarvis.csri.toronto.edu!cs.utexas.edu!usc!zaphod.mps.ohio-state.edu!think!masscomp!mouse!mitchReferences:
<9002281729.AA02895@wilkins.bcm.tmc.edu> <132399@sun.Eng.Sun.COM>Show Full Headers
Complete Article Headers
Path: arc1-ca.pugleaf.net!utzoo!utgpu!jarvis.csri.toronto.edu!cs.utexas.edu!usc!zaphod.mps.ohio-state.edu!think!masscomp!mouse!mitch From: mitch@mouse..westford.ccur.com (Mitchel Kuninsky) Newsgroups: comp.windows.x Subject: Re: Problem with Signals Message-ID: <23695@masscomp.ccur.com> Date: 5 Mar 90 23:19:56 GMT References: <9002281729.AA02895@wilkins.bcm.tmc.edu> <132399@sun.Eng.Sun.COM> Sender: news@masscomp.ccur.com Reply-To: mitch@westford.ccur.com (Mitchel Kuninsky) Organization: Concurrent Computer Corp. Westford MA. Lines: 67