home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1993 #3 / NN_1993_3.iso / spool / comp / unix / programm / 6078 < prev    next >
Encoding:
Text File  |  1993-01-28  |  2.1 KB  |  42 lines
  1. Newsgroups: comp.unix.programmer
  2. Path: sparky!uunet!think.com!paperboy.osf.org!meissner
  3. From: meissner@osf.org (Michael Meissner)
  4. Subject: Re: longjmp() from a signal handler
  5. In-Reply-To: tasos@cs.bu.edu's message of 27 Jan 93 18:04:05 GMT
  6. Message-ID: <MEISSNER.93Jan28145116@tiktok.osf.org>
  7. Sender: news@osf.org (USENET News System)
  8. Organization: Open Software Foundation
  9. References: <rturner.727977268@imagen> <1993Jan26.132457.26298@g2syd.genasys.com.au>
  10.     <rturner.728076215@imagen> <108515@bu.edu>
  11. Date: 28 Jan 93 14:51:16
  12. Lines: 28
  13.  
  14. In article <108515@bu.edu> tasos@cs.bu.edu (Anastasios Kotsikonas) writes:
  15.  
  16. | In article <rturner.728076215@imagen> rturner@imagen.com (Randy Turner) writes:
  17. | #   the the jmp_buf[] references.  The POSIX.1 spec says that only a subset
  18. | #   of library calls are safe to call from inside a signal handler, and the
  19. | #   longjmp()/siglongjmp() calls are not among them.  I was curious if
  20. | #   Sys-V/R4 supports longjmp'ing from a signal handler, or is anyone has
  21. | #   code that does this?
  22. | 
  23. | Yes it does support it and it works fine; the same code actually works fine
  24. | on SUN/HP/IBM/SGI/Stardent/DG under BSD, SVR3 and SVR4.
  25.  
  26. However this discussion is missing the main point (at least as far as
  27. I'm concerned) about longjmp'ing from within signal handlers.  Because
  28. signals are delivered asynchronously, you could be in the library (or
  29. your own code), and be interrupted at the wrong time.  For example,
  30. consider an implementation of malloc that uses a doubly linked list to
  31. hold the free list.  If you are in the middle of calling malloc, your
  32. function may have updated one pointer, but was interrupted before the
  33. other pointer was stored.  Thus your heap is now corrupted, but the
  34. symptoms may not show for a while, but when it does WHAMO.  It may be
  35. that 999,999 times out of a million you are safe, but that doesn't
  36. mean you should blythly write code that fails at unpredictable times.
  37. --
  38. Michael Meissner    email: meissner@osf.org        phone: 617-621-8861
  39. Open Software Foundation, 11 Cambridge Center, Cambridge, MA, 02142
  40.  
  41. You are in a twisty little passage of standards, all conflicting.
  42.