Re: 4gl timer

>From: David Williams <djw@smooth1.demon.co.uk> >Date: Tue, 11 Feb 1997 01:08:32 +0000 >X-Informix-List-Id: <news.33777> > >Jonathan Leffler <johnl@informix.com> writes >>I4GL uses SIGALRM internally while dealing with input -- you can't pre-empt >>this use in your code, I'm afraid. >> >>Using SIGQUIT is interesting -- not usual, but it will work very nicely. >>Good thinking! >> >>[...SIGTERM...SIGHUP...SIGINT...SIGQUIT...not SIGALRM...] >> > How about using SIGUSR1 and SIGUSR2 the "user defined" signals? Yep, they work too. Actually, SIGQUIT has advantages for the signal from the child to the I4GL code -- it is handled automatically by I4GL if you do DEFER QUIT in the MAIN. I've helped write code which used SIGUSR1 to communicate out-of-band event messages, and that can be made to work too. You probably wouldn't really want to do what we did, though. The SIGUSR1 handler would pop up a new window and let the user interact with that -- and then closed the window and returned to where the user left off. That was more or less appropriate for a system where the messages indicated that the production line was failing somehow, and needed to be fixed urgently. The key point is that you cannot (reliably) use SIGALRM to wake the I4GL process -- I4GL thinks it has control of that signal and will get in your way if you try to use it too, especially anywhere near a keyboard interaction statement (INPUT, MENU, ...). Yours, Jonathan Leffler (johnl@informix.com) #include <disclaimer.h>