Path: utzoo!news-server.csri.toronto.edu!cs.utexas.edu!wuarchive!bcm!dimacs.rutgers.edu!mips!smsc.sony.com!dce
From: dce@smsc.sony.com (David Elliott)
Newsgroups: comp.windows.x
Subject: Re: Interrupting an X program... how?
Message-ID: <1991Mar3.034609.8066@smsc.sony.com>
Date: 3 Mar 91 03:46:09 GMT
References: <1991Mar1.045842.21676@contact.uucp> <1991Mar2.183352.29822@progress.com>
Organization: Sony Microsystems Corp, San Jose, CA
Lines: 25

In article <1991Mar2.183352.29822@progress.com> mikep@progress.COM (Mike Pacholec) writes:
>egr@contact.uucp (Gordan Palameta) writes:
>>Specifically, a program which goes off and does lengthy
>>calculations, and doesn't check for X events until the calculations
>>are complete.

>I haven't seen any other suggestions.

I mailed mine, but I know of two ways to handle this type of situation.

The first is to code the lengthy processing such that it can go for a
while and then suspend processing to allow for events.  Under Xt, a
WorkProc can be used for this.  With Xlib, you just call the routine
when there are no pending X events.

The second is to split the entire program into two Unix processes, one
handling the user interface and the other doing the calculations.  If
you have shared memory or if the interaction can be done simply with
pipes (i.e., not a lot of complex data needs to be shipped around),
this isn't bad at all.

Personally, I prefer the first method, but it can be tough to code and
require a lot of state data.  The second method has the advantage that
the meat of the task is separated completely from the interface, which
can be great if you need to provide multiple interfaces eventually.