Path: utzoo!utgpu!jarvis.csri.toronto.edu!cs.utexas.edu!usc!wuarchive!texbell!texsun!newstop!sun!turnpike!argv
From: argv%turnpike@Sun.COM (Dan Heller)
Newsgroups: comp.windows.x
Subject: Re: Problem with Signals
Message-ID: <132608@sun.Eng.Sun.COM>
Date: 7 Mar 90 02:30:35 GMT
References: <9002281729.AA02895@wilkins.bcm.tmc.edu> <132399@sun.Eng.Sun.COM> <4429@quanta.eng.ohio-state.edu> <1174@sdrc.UUCP>
Sender: news@sun.Eng.Sun.COM
Reply-To: argv@sun.UUCP (Dan Heller)
Lines: 44

In article <1174@sdrc.UUCPevgabb@sdrc.UUCP (Rob Gabbard) writes:

    This wouldn't solve the original problem I had that started all this. I
    wanted a way for my process to wake up periodically and flush out the
    event queue to keep it from overflowing. For instance, what if I had a
    model solver that was going to take 7 hours to run a solve on a model.
    The user clicks a SOLVE widget and its out of the event loop for 7
    hours. During that time all kinds of events could be received into the
    queue and not serviced causing it to eventually overflow. I wanted to
    use setitimer and signal to periodically check the queue, but the
    problems I had are what started this discussion.

There are two ways to address this problem.  First and foremost,
you need to redesign this user interface.  You should never have
a function that takes that much time an run it in a callback
routine.  That type of processing should either be done in a
separate process, or you need to read and dispatch events within
that cpu-intensive routine.

Secondly, given that you *have* to run this 7-hour routine, you
should not decide to use the timer signal to test for user events.
If you do, you're perpetuating the same problem that started this.
That is, the signal handler may still be interfering with any Xlib
calls you may be executing since you would be using Xlib to test
for and deal with events.

Let me be more explicit.  If you want to write a long time-consuming
or CPU intensive routine, then the problem of reading/waiting for
events should be handled manually.  Edit the cpu-intensive routine
and insert locations in which you can call XPending(), XReadEvent()
or XDispatchEvent() as needed.  Do not use a itimer to do this for you.

If you can't edit that routine, then you should spawn a new process
and execute it.  I doubt this is the case, however.  If you are using
Xview, the Notifier is really handy for stuff like this and there is
a chapter that addresses this type of activity in the XView Programmer's
Manual (Volume 7 of the O'Reilly series on X programming).
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
    Opinions expressed reflect those of the author only.