Re: Fix signal handler

From: Jeff King <peff@peff.net>
Date: Feb 3, 2010, 10:29 UTC
Message-ID: <20100203102915.GA25486@coredump.intra.peff.net>
In-Reply-To: <4B694DEE.5030207@web.de>

On Wed, Feb 03, 2010 at 11:20:30AM +0100, Markus Elfring wrote:

Show 6 quoted lines

> > I don't think anyone here is much interested in whether there is any
> > sort of guarantee on a particular construct working.
> 
> That is a pity. - I would expect that professional software development
> will build on working specifications instead of potentially undefined
> behaviour.

I think it is simply impractical. It's not that we're ignoring a specification, it's that there _isn't_ a concrete specification for the set of systems we're interested in.

Show 10 quoted lines

> > So to answer your question, I honestly don't know. The code may well
> > be broken on common platforms and it is simply a race condition that
> > has never come up. But I do know that it has not been a common source
> > of bug reports, which makes me not want to spend time investigating
> > it when nobody has demonstrated its incorrectness beyond mentioning
> > a standards document.
> [...]
> I find that programming errors in this area might be hard to identify
> from the outside because resulting race conditions and deadlocks fall
> into the symptom category of heisenbugs, don't they?

Yes, they can be hard to identify from the outside. But if you are interested in addressing the situation, I am suggesting that the first step would be to demonstrate that there in fact _is_ a race condition, and it is not simply some theoretical problem.

-Peff