From: widener!obelix.informix.com!johnl@emory.mathcs.emory.edu (Jonathan Leffler)
Newsgroups: comp.databases.informix
Subject: Re:  Catching SIGHUP signals in Informix-4GL programs
Date: 21 Aug 92 15:53:07 GMT
Reply-To: widener!obelix.informix.com!johnl@emory.mathcs.emory.edu (Jonathan Leffler)
X-Informix-List-ID: <list.1390>

>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>