Re: signal handlers

On Wed, Nov 25, 2015 at 9:54 AM, Bob Friesenhahn
<[email protected]> 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.

------------------------------------------------------------------------------
Go from Idea to Many App Stores Faster with Intel(R) XDK
Give your users amazing mobile app experiences with Intel(R) XDK.
Use one codebase in this all-in-one HTML5 development environment.
Design, debug & build mobile apps & 2D/3D high-impact games for multiple OSs.
http://pubads.g.doubleclick.net/gampad/clk?id=254741551&iu=/4140