Path: utzoo!utgpu!jarvis.csri.toronto.edu!clyde.concordia.ca!uunet!sdrc!evgabb From: evgabb@sdrc.UUCP (Rob Gabbard) Newsgroups: comp.windows.x Subject: Re: Problem with Signals Summary: Nope - not as events Message-ID: <1174@sdrc.UUCP> Date: 5 Mar 90 13:33:03 GMT References: <9002281729.AA02895@wilkins.bcm.tmc.edu> <132399@sun.Eng.Sun.COM> <4429@quanta.eng.ohio-state.edu> Organization: SDRC, Cincinnati Lines: 23 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. -- ________ _________ _______ ________ / _______| | ____ \ | ___ \ / _______| Rob Gabbard (uunet!sdrc!evgabb) | |______ | | \ \ | | \ | | / Technical Development Engineer \_______ \ | | | | | |___/ / | | Structural Dynamics Research Corp. ______| | | |____/ / | ____ \ | \_______ #include |________/ |________/ |_| |_| \________|