[ILUG] Signal handling thing

[Brian Foster]

  | Date: Wed, 26 Jun 2002 11:57:07 +0200
  | From: David Neary <dneary at wanadoo.fr>
  | 
  | Hi all,
  | 
  | This is kind of puzzling me - I'm sure I've done stuff similar
  | to this a million tomes, but I'm having trouble getting this
  | working. Can anyone see what I'm doing wrong here?
  | 
  | Basically I'm expecting signal 42 (MYSIG) to be raised an
  | indefinite number of times, until I raise SIGINT in the usual
  | manner. But I'm getting a system "Real-time signal 10" message,
  | and the program exits, after the first call (presumably, when my
  | sign-handler's called a second time). Any idea why? Something
  | idiotic I'm missing?

 easy.  the implementation of signal(2) you are using is probably
 following the original Unix semantics of reseting the handler to
 SIG_DFN when the signal is delivered.  so what's happening is the
 1st MY_SIG is raise(3)ed and delivered Ok, but that delivery resets
 MY_SIGs handler to SIG_DFN.  hence, there is no handler to catch
 the 2nd `raise', and hence the program exits (which is the default
 action on most signals, including, I presume, MY_SIG).

 the ``Real-time ...'' message is being printed by your shell in
 response to the imputed _exit(2) status; indeed, note that on many
 systems, SIGRTMIN+10 == 42, which is MY_SIG ....

 best fix (IMHO) is to use sigaction(2), not signal(2).  b.t.w.,
 this example is precisely why I recommend _never_ using `signal'
 (provided `sigaction' is available).

 also, AFAIK, printf(3) and friends are not considered signal safe
 (i.e., are "unsafe" in ANSI C89), and hence, in theory, should
 never be used in a signal hander.

 and, pedantic point time, POSIX.4 (or .1c or whatever it is now)
 says SIGRTMIN needn't be a compile-time constant.  hence, it is
 pedantically incorrect to simply define MY_SIG as a constant;
 it should _always_ be defined in terms of SIGRTMIN.

cheers!
	-blf-
--
 Innovative, very experienced, Unix and      | Brian Foster    Dublin, Ireland
 Chorus (embedded RTOS) kernel internals     | e-mail: blf at utvinternet.ie
 expert looking for a new position ...       | mobile: (+353 or 0)86 854 9268
  For a résumé, contact me, or see my website  http://www.blf.utvinternet.ie

    Stop E$$o (ExxonMobile):  «Whatever you do, don't buy Esso --- they
     don't give a damn about global warming.»    http://www.stopesso.com
     Supported by Greenpeace, Friends of the Earth, and numerous others...