Re: Fix signal handler

From: Daniel Barkalow <barkalow@iabervon.org>
Date: Feb 9, 2010, 23:49 UTC
Message-ID: <alpine.LNX.2.00.1002091812290.14365@iabervon.org>
In-Reply-To: <4B71A2EE.8070708@web.de>

On Tue, 9 Feb 2010, Markus Elfring wrote:

Show 17 quoted lines

> 
> >
> > If you can demonstrate a practical problem and provide a patch, then I
> > am sure people would be happy to read it.
> >   
> 
> I need a few further clarifications on this issue to choose a potential fix.
> 
> I have noticed that the variable "show_early_output" gets a value
> assigned only at a few places in the source code. I wonder that the set
> pointer is only used by the function "limit_list" to call the function
> "log_show_early" on demand.
> http://git.kernel.org/?p=git/git.git;a=blob;f=revision.c;h=3ba6d991f6e9789949c314c2981dfc6b208a6f66;hb=HEAD#l683
> 
> I find that a simple flag would be sufficient. I see no need to handle
> different function pointers here. Do any objections exist to achieve the
> same effect with the data type "sig_atomic_t"?

In that particular instance, there's actually a comment that says it uses an int (which is almost certainly what sig_atomic_t is, but sig_atomic_t might not be defined on some actual platforms). Making the code match the comment, at least, would be good.

In particular, function pointers are more likely than other pointers to be not a machine word. I'm pretty sure that an IA64 machine could potentially have a race with a small window here.

As to whether to use int (as the comment says) or sig_atomic_t, I don't really have any idea which would have fewer problems.

	-Daniel
*This .sig left intentionally blank*