home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1992 #18 / NN_1992_18.iso / spool / comp / database / informix / 1766 < prev    next >
Encoding:
Internet Message Format  |  1992-08-21  |  3.4 KB
  1. Path: sparky!uunet!paladin.american.edu!europa.asd.contel.com!emory!emory.mathcs.emory.edu
  2. From: widener!obelix.informix.com!johnl@emory.mathcs.emory.edu (Jonathan Leffler)
  3. Newsgroups: comp.databases.informix
  4. Subject: Re:  Catching SIGHUP signals in Informix-4GL programs
  5. Message-ID: <9374@emory.mathcs.emory.edu>
  6. Date: 21 Aug 92 15:53:07 GMT
  7. Sender: walt@mathcs.emory.edu
  8. Reply-To: widener!obelix.informix.com!johnl@emory.mathcs.emory.edu (Jonathan Leffler)
  9. Lines: 65
  10. X-Informix-List-ID: <list.1390>
  11.  
  12. >From: uunet!isbank.is!stb (Steintor Bjarnason)
  13. >Subject: Catching SIGHUP signals in Informix-4GL programs
  14. >Date: 20 Aug 92 15:13:53 GMT
  15. >X-Informix-List-Id: <news.1683>
  16. >
  17. >I was reading through the Informix-4gl supplement manual which came
  18. >with Informix-4GL v4.1 and I found the following clause (page S-205):
  19. >
  20. >  ... You cannot control the processing that occurs when the SIGHUP or
  21. >  SIGPIPE interrupt is detected, even though the program catches these
  22. >  values.
  23. >
  24. >If I understand this clause correctly then there is no way for me
  25. >to do my own cleanup when I receive SIGHUP ????
  26. >
  27. >If this is correct then I consider this a MAJOR bug because I need to
  28. >be able to detect when users log out (My users are connected through
  29. >an X.25 pad which sends SIGHUPs when the connection is cleared).
  30. >
  31. >If this is true, then is there some way around this "feature" ?
  32.  
  33. Several comments:
  34.  
  35. 1. These are my views, not Informix's.  Any suggestions made in this
  36.    message are unsupported.
  37.  
  38. 2. Experience leads me to think that I4GL code ignores both SIGHUP and
  39.    SIGTERM, despite what it says in the Supplement.
  40.  
  41. 3. Experience also tells me this is a confounded nuisance and only
  42.    encourages people to use SIGKILL to deal with I4GL programs, because
  43.    nothing else does kill them reliably.  This is dangerous as they then
  44.    use SIGKILL for everything, which leads to problems with OnLine.
  45.  
  46. 4. The statement in the supplement is correct if you consider using I4GL
  47.    only.  However, if you delve into C, you may be better off.
  48.  
  49. 5. The signal(2) system call is used to install signal handlers.  When
  50.    you change the signal handler, it returns the previously installed
  51.    signal handler.
  52.  
  53. 6. This being the case, you could try the following scenario:
  54.     -- call some C to install your own SIGHUP handler, keeping a note of
  55.        the I4GL handler.
  56.     -- your handler would arrange to ignore SIGHUP.
  57.     -- your own handler would call the Informix handler (maybe!).
  58.     -- your handler would reset the signal handling back to itself AFTER
  59.        the Informix handler had been called.
  60.  
  61. 7. The "maybe" is because if the Informix handler does a longjmp(), then
  62.    your handler won't get the opportunity to reset itself, and the Informix
  63.    handler is almost certain to try installing itself as the handler so
  64.    you would be stuck.
  65.  
  66. 8. The notes in the Supplement say that I4GL tries to clear the screen
  67.    before terminating the program.  This is of dubious value.  It should
  68.    (probably) set the terminal back to the startup setting, but clearing
  69.    the screen after the comms line has gone is generally not a good idea.
  70.    Certainly, I had to stop doing that on a machine where I use a modem for
  71.    access, because trying to clear the screen on SIGHUP locked the modem up
  72.    so I couldn't get back in again -- kind of inconvenient at the weekend
  73.    when the adminstrative staff aren't there.
  74.  
  75. Yours unsupportedly,
  76. Jonathan Leffler (johnl@obelix.informix.com) #include <disclaimer.h>
  77.