Re: Fix signal handler

From: Markus Elfring <markus.elfring@web.de>
Date: Feb 3, 2010, 11:55 UTC
Message-ID: <4B696447.10803@web.de>
In-Reply-To: <20100203102915.GA25486@coredump.intra.peff.net>

>
> I think it is simply impractical.

I have got the opposite opinion.

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

I have got doubts on your view. Known specifications are available for POSIX and corresponding programming languages like C and C++. I know that they have got open issues on their own because a few important wordings are not as precise and clear as you might prefer.

For which software environments do you miss programming standards?

How many efforts would you like to spend on conditional compilation for "special" platforms?

Show 5 quoted lines

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

I try to point out this open issue once more.

Can you imagine any unwanted results if the desired address can not be atomically set in a way that fulfils requirements for signal handler implementations? Can it happen that the assigned function pointer will become a dangling pointer because of word-tearing?

Another "dangerous" use case: Do you know if any function is called during the execution in a signal handling context that is not async-signal-safe like "fprintf()"?

Regards, Markus