Path: utzoo!utgpu!news-server.csri.toronto.edu!rpi!zaphod.mps.ohio-state.edu!wuarchive!uunet!ora!bloom-beacon!dont-send-mail-to-path-lines
From: mouse@lightning.mcrcim.mcgill.EDU (der Mouse)
Newsgroups: comp.windows.x
Subject: Re:  SIGIO/SIGALRM in conflict with XLib ?
Message-ID: <9105021507.AA18962@lightning.McRCIM.McGill.EDU>
Date: 2 May 91 15:07:47 GMT
Sender: daemon@athena.mit.edu (Mr Background)
Organization: The Internet
Lines: 50

> I have a program for displaying X-ray images.  The program has been
> up running for a couple of months at this time.  I'm now working with
> an audio expansion to the program.

> The audio part is set up to receive SIGIO interrupts when it is time
> to read/write from/to the audio device.  The program also receives
> SIGALRM interrupts that I use to display the peek level of the audio
> and to show record/play time.  At each SIGALRM interrupt I send 1-2
> draw requests to the X server.

Danger, danger.

> Both the imaging part and the audio part work if I run them one at a
> time.  BUT it crash every time when I'm recording/playing and at the
> same time use the imaging part.

Yup.

> My guess is that the program is doing a XLib call from the imaging
> part and at the same time receives a SIGALRM interrupt generating
> another XLib request before the first request is carried through.

This is basically correct.

Almost all implementations of Xlib do not contain code to interlock
correctly with themselves when called both from signal handlers and
from the code that can be interrupted by the signal.

Basically, you have to make sure that you never make Xlib calls from
within a signal handler that might have interrupted an Xlib call.  (If
you want to live dangerously: you probably can get away with this
provided they do not share any Xlib data; in particular, they must not
use the same Display connection.)

How you arrange this is up to you.  You can have the signal handler
dump something in global variables for the main-line to notice and act
on, you can use sigblock() to block delivery of the relevant signals
while doing Xlib operations (I assume you have sigblock() because you
have SIGIO), or anything else with the same result.

Since you appear to be running under UNIX, you might consider forking
and splitting responsibilities.  But note that if you do that, the two
processes cannot share a single display connection, not even if you
take care that they don't both try to use it at once; each process that
needs to do X operations must use its own connection.

					der Mouse

			old: mcgill-vision!mouse
			new: mouse@larry.mcrcim.mcgill.edu