home *** CD-ROM | disk | FTP | other *** search
/ Usenet 1994 January / usenetsourcesnewsgroupsinfomagicjanuary1994.iso / sources / std_unix / volume.31 / text0050.txt < prev    next >
Encoding:
Text File  |  1993-07-15  |  1.8 KB  |  48 lines
  1. Submitted-by: wulkan@vnet.IBM.COM (Mike Wulkan)
  2.  
  3. Let me set the stage:
  4.  
  5. 1)  ANSI C Standard Section 4.10.4.1 abort():
  6.     "...causes abnormal program termination to occur, unless the signal
  7.     SIGABRT is being caught and the signal handler does not return.  ...
  8.     is returned to the host environment by means of the function call
  9.     raise(SIGABRT)."
  10.  
  11. 2)  Posix .4a Section 2.2.1.136:
  12.     "Asynchronously generated signal: A signal which is not
  13.     attributable to a specific thread.  Examples are signals sent via
  14.     kill(), ..."
  15.  
  16. 3)  Posix .4a Section 8.4.6.2:
  17.     "The C standard raise() function...  The effect of this function in
  18.     a POSIX.4a process shall be equivalent to calling
  19.     kill(getpid(),sig).  The signal specified shall be asynchronously
  20.     generated, regardless of the signal number, providing the signal
  21.     number is valid."
  22.  
  23. I think that it is pretty clear from the above that abort() causes an
  24. asynchronous SIGABRT signal to be generated.  So how do you achieve the
  25. semantics required by (1) if the SIGABRT signal is delivered to a thread
  26. other than the one that issued the abort() call?  What you end up with
  27. is a race condition between the thread that is executing the SIGABRT
  28. signal handler and the thread that issued the abort() function call
  29. terminating the program!  AND the method of exiting the signal handling
  30. function has NO influence on whether the program will be terminated.
  31. This is a direct violation of ANSI C.
  32.  
  33. Even in the case where the SIGABRT signal is delivered to the same
  34. thread that issued the abort() function call, since the signal is
  35. asynchronous, there is NO guarantee that it will be delivered before the
  36. abort() function initiates termination of the program.
  37.  
  38. Can someone please point out something in the ANSI, POSIX.1 and/or
  39. POSIX.4a that gets me out of this quandary?
  40.  
  41. Thanks,
  42.  
  43. Mike Wulkan
  44.  
  45.  
  46. Volume-Number: Volume 31, Number 53
  47.  
  48.