home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1993 #3 / NN_1993_3.iso / spool / comp / unix / programm / 6069 < prev    next >
Encoding:
Text File  |  1993-01-28  |  1.5 KB  |  36 lines
  1. Newsgroups: comp.unix.programmer
  2. Path: sparky!uunet!charon.amdahl.com!amdahl!rtech!sgiblab!munnari.oz.au!yarrina.connect.com.au!warrane.connect.com.au!g2syd!michaelh
  3. From: michaelh@g2syd.genasys.com.au (Michael Haldey)
  4. Subject: Re: longjmp() from a signal handler
  5. Message-ID: <1993Jan28.015353.18940@g2syd.genasys.com.au>
  6. Keywords: longjmp signals
  7. Organization: Genasys II, Sydney, Australia
  8. References: <rturner.727977268@imagen> <1993Jan26.132457.26298@g2syd.genasys.com.au> <rturner.728076215@imagen>
  9. Date: Thu, 28 Jan 1993 01:53:53 GMT
  10. Lines: 24
  11.  
  12. In article <rturner.728076215@imagen> rturner@imagen.com (Randy Turner) writes:
  13. ...
  14. >   But from within a signal handler, even siglongjmp() is not compatible.
  15. >   I think the problem stems from the fact that signal delivery is an
  16. >   implementation-specific issue and that POSIX cannot guarantee that the
  17. >   runtime stack the signal is delivered on is the same runtime stack that
  18. >   the the jmp_buf[] references.  
  19.  
  20. You can specify alternative stack, there are ways to do it.
  21.  
  22. >                      The POSIX.1 spec says that only a subset
  23. >   of library calls are safe to call from inside a signal handler, and the
  24. >   longjmp()/siglongjmp() calls are not among them.  I was curious if
  25. >   Sys-V/R4 supports longjmp'ing from a signal handler, or is anyone has
  26. >   code that does this?
  27. >                Randy
  28.  
  29. Absolutely correct, but the reason is not in the stack.
  30.  
  31. Michael
  32. -- 
  33. Michael Haldey  |  Genasys II Pty Ltd, Sydney, Australia
  34.                 |  Phone:    +61-2-954-2878 (-9930 FAX)
  35.                 |  Internet: michaelh@g2syd.genasys.com.au
  36.