Hi,
On Mon, May 26, 2008 at 10:36:45PM +0100, Johannes Schindelin wrote:
> > 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.
> > 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
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
