Re: [PATCH] lockfile: reset the correct signal

From: Clemens Buchacher <drizzd@aon.at>
Date: May 27, 2008, 07:49 UTC
Message-ID: <20080527074903.GA2403@localhost>
In-Reply-To: <alpine.DEB.1.00.0805262234210.30431@racer>

Hi,

On Mon, May 26, 2008 at 10:36:45PM +0100, Johannes Schindelin wrote:

Show 6 quoted lines

> > On Mon, May 26, 2008 at 10:34:11AM +0100, Johannes Schindelin wrote:
> > > Only from the patch did I understand that you actually meant:
> > 
> > Thank you for fixing that.
> 
> Unfortunately, the original patch is already in git.git.

I will be more careful with my commit messages in the future.

Show 7 quoted lines

> > I also realized that using signals like that can cause races. Shouldn't 
> > we use sigaction() instead of signal()?
> 
> Dunno.  The man page suggests it, but we have plenty of cases where we use 
> signal().  And I think it might be less painful to implement a 
> compat-wrapper for the platforms which differ from Linux' interpretation 
> of signal().

On the other hand, sigaction is used already in two places. What do you think about replacing all those calls to signal/sigaction with something like this?

void set_signal(int signo, void (*handler)(int), int sa_flags)
{
	struct sigaction sa;

	memset(&sa, 0, sizeof(sa));
	sa.sa_handler = handler;
	sa.sa_flags = sa_flags;
	sigemptyset(&sa.sa_mask);
	sigaction(signo, &sa, NULL);
}

The behavior won't change, except that handlers cannot be interrupted by their own signal.

Clemens