🚀 go-pugleaf

In article <1174@sdrc.UUCP> evgabb@sdrc.UUCP (Rob Gabbard) writes:
>In article <4429@quanta.eng.ohio-state.edu>, JONESD@kcgl1.eng.ohio-state.edu (David Jones) writes:
>> Instead of hacking up tookits to allow your application to add signal handlers,
>> I'd rather see them hacked up to convert signals into client events.  The
>> application would deal with with the signal as another event to deal and
>> not as something to be dealt with by a signal handler.
>
>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.

In this example, you should use two processes.  One does the 7 hour calculation,
the other handles the window interface.

If you were to use XView for this, you would not even need signal handling
since you can set up an input function to read the output of the program
when it's available.

A two process model is much easier to implement and more reliable than 
what you've proposed.

As an added benefit, you could set the "nice" value of your calculating
process so it does not kill your user interaction time while processing.

Regards,

Heather