home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1992 #18 / NN_1992_18.iso / spool / comp / os / linux / 8075 < prev    next >
Encoding:
Text File  |  1992-08-12  |  1.9 KB  |  42 lines
  1. Newsgroups: comp.os.linux
  2. Path: sparky!uunet!gumby!yale!mintaka.lcs.mit.edu!bloom-picayune.mit.edu!daemon
  3. From: tytso@ATHENA.MIT.EDU (Theodore Ts'o)
  4. Subject: Re: Return from signal handler??
  5. Message-ID: <1992Aug13.014830.28283@athena.mit.edu>
  6. Sender: daemon@athena.mit.edu (Mr Background)
  7. Reply-To: tytso@ATHENA.MIT.EDU (Theodore Ts'o)
  8. Organization: The Internet
  9. Date: Thu, 13 Aug 1992 01:48:30 GMT
  10. Lines: 30
  11.  
  12.    From: Philip Balister <balister@pdsrvr.salem.ge.com>
  13.    Reply-To: balister@pdsrvr.salem.ge.com
  14.    Date: Wed, 12 Aug 1992 19:52:05 GMT
  15.  
  16.    A guy where I work is trying to use the signal mechanism of Lynxos to set
  17.    a global variable to indicate a floating point error by trapping floating
  18.    point exceptions signals. What he found was that the signal handler seems
  19.    to return to the line that caused the signal, causing it to happen again,
  20.    not what he wanted! 
  21.  
  22. That is in fact the correct behavior.  If you catch something like a
  23. segmentation violation or a FP exception, it is up to your signal
  24. handler to either fix the registers or otherwise make sure that the
  25. problem won't happen again before you return.  Most signal handlers for
  26. SEGV and FPE just do some cleanup work and then exit(); they do not
  27. return back to the program.
  28.  
  29. An exception to this is how old versions of the Bourne shell did memory
  30. management.  Malloc() would just hand out memory allocations without
  31. actually doing anything to make sure that the memory was there.  Then,
  32. the first time the bourne shell tried to use the pointer, it would get a
  33. SIGV, which was trapped by a signal handler.  That signal handler then
  34. did the sbrk() command so that the faulting instruction would success
  35. this time around, and returned.  
  36.  
  37. Needless to say, this was horrible design and not particularily portable
  38. to other platforms.  But it illustrates the rare example of where you
  39. actually return from a signal handler for SIGSEGV or SIGFPE.  
  40.  
  41.                             - Ted
  42.