It's just bad practice IMO to introduce a race condition like this in the
middle of library code. Granted signals are a poor way to catch some conditions
but if I'm writing code I really don't want library routines causing 
unexpected behaviour.

What's really needed is a util routine which returns a list of function 
pointers for all signals.

James

>
>On Thu, Aug 24, 2000 at 10:58:23AM -0400, James Chacon wrote:
>> 
>> Ok, it's been a while since I wrote lots of signal code, but how exactly would
>> you query the current signal handler without changing it? sigaction/signal
>> only return the previous handler after you change it which is definitly not
>> what I'd want a library routine doing (race conditions, etc).
>> 
>If you're willing to change in the first palce, just put it back if it
>wasn't what you expected.  From (bad) memory:
>
>	s = signal (SIGINT, SIG_IGN);
>	if (s != SIG_DFL)
>		signal (SIGINT, s);
>
>This isn't exactly worse than what you'd have done anyway, is it?
>There's a very small period during which the ^C may be ignored, but I
>really can't imagine it being long enough for anyone to race it, not
>even expect :-)
>
>Don't forget to put it back if it stays changed.
>
>I hope I'm not leading you up the garden path.
>
>++L
>
>
>
>