Re: signal handlers

On Tue, 24 Nov 2015, James Bardin wrote:

> Hi Bob,
>
> When GraphicsMagick installs its signal handlers, it first replaces
> the existing handler, checks if it was SIG_DFL, and reinstalls the
> previous handler if it wasn't. The problem with this is that is it
> doesn't set any flags that the previous handler may have had.
> MagickCondSignal should probably first check if the handler is SIG_DFL
> before installing a new one.

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.

> 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.

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.

To achieve success, there likely needs to be a version of 
MagickCondSignal() for when sigaction() is not available.

Programs could use the work-around to set their own signal handlers 
after invoking InitializeMagick().  This might not be so easy if they 
are using the GraphicsMagick library via another library.

Regardless, if a problem occurs while in GraphicsMagick code, it is 
important for the program to cause PanicDestroyMagick() to be invoked 
before the program exists in order to assure that any active temporary 
files are deleted.  Other than due to a logic bug in GraphicsMagick, 
temporary files should be naturally cleaned up before the function 
which created them returns.

Bob
-- 
Bob Friesenhahn
[email protected], http://www.simplesystems.org/users/bfriesen/
GraphicsMagick Maintainer,    http://www.GraphicsMagick.org/

------------------------------------------------------------------------------
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