Re: Catching SIGHUP signals in Informix-4GL programs

>From: uunet!isbank.is!stb (Steintor Bjarnason) >Subject: Catching SIGHUP signals in Informix-4GL programs >Date: 20 Aug 92 15:13:53 GMT >X-Informix-List-Id: <news.1683> > >I was reading through the Informix-4gl supplement manual which came >with Informix-4GL v4.1 and I found the following clause (page S-205): > > ... You cannot control the processing that occurs when the SIGHUP or > SIGPIPE interrupt is detected, even though the program catches these > values. > >If I understand this clause correctly then there is no way for me >to do my own cleanup when I receive SIGHUP ???? > >If this is correct then I consider this a MAJOR bug because I need to >be able to detect when users log out (My users are connected through >an X.25 pad which sends SIGHUPs when the connection is cleared). > >If this is true, then is there some way around this "feature" ? Several comments: 1. These are my views, not Informix's. Any suggestions made in this message are unsupported. 2. Experience leads me to think that I4GL code ignores both SIGHUP and SIGTERM, despite what it says in the Supplement. 3. Experience also tells me this is a confounded nuisance and only encourages people to use SIGKILL to deal with I4GL programs, because nothing else does kill them reliably. This is dangerous as they then use SIGKILL for everything, which leads to problems with OnLine. 4. The statement in the supplement is correct if you consider using I4GL only. However, if you delve into C, you may be better off. 5. The signal(2) system call is used to install signal handlers. When you change the signal handler, it returns the previously installed signal handler. 6. This being the case, you could try the following scenario: -- call some C to install your own SIGHUP handler, keeping a note of the I4GL handler. -- your handler would arrange to ignore SIGHUP. -- your own handler would call the Informix handler (maybe!). -- your handler would reset the signal handling back to itself AFTER the Informix handler had been called. 7. The "maybe" is because if the Informix handler does a longjmp(), then your handler won't get the opportunity to reset itself, and the Informix handler is almost certain to try installing itself as the handler so you would be stuck. 8. The notes in the Supplement say that I4GL tries to clear the screen before terminating the program. This is of dubious value. It should (probably) set the terminal back to the startup setting, but clearing the screen after the comms line has gone is generally not a good idea. Certainly, I had to stop doing that on a machine where I use a modem for access, because trying to clear the screen on SIGHUP locked the modem up so I couldn't get back in again -- kind of inconvenient at the weekend when the adminstrative staff aren't there. Yours unsupportedly, Jonathan Leffler (johnl@obelix.informix.com) #include <disclaimer.h>