Path: utzoo!utgpu!jarvis.csri.toronto.edu!mailrus!uwm.edu!zaphod.mps.ohio-state.edu!think!snorkelwacker!bloom-beacon!LARRY.MCRCIM.MCGILL.EDU!mouse
From: mouse@LARRY.MCRCIM.MCGILL.EDU (der Mouse)
Newsgroups: comp.windows.x
Subject: Re:  Don't bother using signals at all
Message-ID: <9003101127.AA21750@Larry.McRCIM.McGill.EDU>
Date: 10 Mar 90 11:27:13 GMT
Sender: daemon@athena.mit.edu (Mr Background)
Organization: The Internet
Lines: 39

>> For instance, what if I had a model solver that was going to take 7
>> hours to run a solve on a model.

> Don't bother with signals.  Use this totally different approach,
> which sounds bizarre at first but works wonderfully, allowing events
> to be processed normally while your long processing goes on.  It
> makes use of the XView Notifier

Fine, provided you're willing to tie yourself to systems where all the
ugly tricks XView uses will work.

> Before starting any event loop, call pipe(2) to get the two ends of a
> pipe as file descriptors.  [...] [W]e're going to use it to talk to
> ourself!

Be very careful here.  Is it guaranteed a pipe is buffered?  I don't
think the specified semantics forbid an implementation where a write
blocks until all data have been read.

Oh yes, I forgot.  We're willing to make all sorts of system-specific
assumptions.

> The solve() procedure can fork a separate process (and possibly nice
> it) if you want; you could then have a STOP button that killed the
> child to stop solving.

If you're going to do *that*, there's no problem to begin with.

> I know, I know, programs that talk to themselves are sick;

Well, dubious at least.  You will probably get away with it just fine,
but wait for the day when you're writing that one byte too many, or
(potentially) the system is short of mbufs, and you deadlock with
yourself....

					der Mouse

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