home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1992 #30 / NN_1992_30.iso / spool / comp / lang / c / 18350 < prev    next >
Encoding:
Text File  |  1992-12-14  |  2.4 KB  |  50 lines
  1. Newsgroups: comp.lang.c
  2. Path: sparky!uunet!spillman!tye
  3. From: tye@spillman.uucp (E. Tye McQueen)
  4. Subject: Re: longjumping out of a signal handler
  5. Message-ID: <1992Dec14.223422.39678@spillman.uucp>
  6. Date: Mon, 14 Dec 1992 22:34:22 GMT
  7. References: <1992Dec7.121124.3737@cs.utwente.nl> <1992Dec8.113719.22463@cs.utwente.nl> <1992Dec09.185512.33137@spillman.uucp> <1992Dec11.120446.28991@cs.utwente.nl>
  8. Organization: Spillman Data Systems
  9. Lines: 39
  10.  
  11. ahoekstr@cs.utwente.nl (Andre D. Hoekstra) writes:
  12. )But if your implementation of signal handlers blocks overrun signals by
  13. )setting a flag on entry in your signal handler, and clearing it on exit,
  14. )you may get stuck with a masked signal, by not exiting from the handler.
  15. )(longjump prevents exit/return obviously). Unless signal clears this
  16. )flag for the signal at hand explicitly you are unsafe.
  17.  
  18. Well, it is nice to know that some (pre-ANSI?) system have this
  19. problem.  Anyone have a list of *which* systems have this problem?
  20.  
  21. K&R II doesn't talk about any of this and my copy of the standard
  22. is way outdated, so maybe I'm wrong; but I distinctly recall that
  23. ANSI guarantees only two things that can be done within a signal
  24. handler:  1) Set a variable of type "sig_atomic_t"  and  2) Call
  25. longjump().
  26.  
  27. If so, how do such systems conform to ANSI C?  Does setjump() save
  28. the signal mask and longjump() restores it?  Is there some require-
  29. ment that I reset the signal myself from within the handler before
  30. calling longjump()?  Or is this just an OS "bug" that newer systems
  31. no longer have?  (I mean, longjump(), if anything, is for exception
  32. handling as are signals so it doesn't make sense to design a system
  33. where they can't be used together.)
  34.  
  35. I'm not arguing that using longjump() within a signal handler is in
  36. fact safe on all systems.  It clearly is not.  But I don't think
  37. setting a global flag in the signal handler and checking it in a
  38. calling routine will work on all systems either (see below).
  39.  
  40. Anyone know which systems restart system calls for you in a way that
  41. prevents you from interrupting them with a caught signal so you can
  42. see if your "sig_atomic_t" flag has been set?  Seems like this was a
  43. BSDism.  Is this behavior disallowed by ANSI C, Posix, etc.?
  44.  
  45. Thanks,
  46.  tye@spillman.com                         Tye McQueen, E.
  47. ----------------------------------------------------------
  48.  Nothing is obvious unless you are overlooking something. 
  49. ----------------------------------------------------------
  50.