From: James B. <j.b...@gm...> - 2015-11-25 15:26:37
|
On Wed, Nov 25, 2015 at 9:54 AM, Bob Friesenhahn <bfr...@si...> wrote: > This is a good point. Besides flags, there already may be > thread-specific signal handling/masking. Signals can be extremely > complicated and behavior is not identical across systems. > Precisely. This came up because of a system I have where signals can cause deadlocks, segfaults, etc because of missing flags. >> Here's an example patch to check the handler first (not really tested, >> just compiled). It's not pretty since it just uses SIG_ERR to skip >> reinstalling the old reinstallation step, but should show the intent: > > This seems to be modifying MagickSignal(). I would prefer not to > modify MagickSignal(). It would be better to have a new function to > specifically test if signal handling is still defaulted. > Yes, I agree. This was a quick example I made to get around the problem. Previously I was just patching out the signal handler registration altogether ;) > A problem is what to do if sigaction() is not available. I do not see > anything in the signal() documentation which suggests that a NULL > function pointer can be passed in order to test for the current > handler. It is likely to just crash the program on some systems. > This is probably why I used the current implementation approach. > I would probably leave the current behavior if sigaction() isn't available. If there's no sigaction(), I don't know if there's anything better you can do. At least on Linux, the man page says to avoid the use of signal() altogether, and its effects in a multithreaded process are unspecified. |