On Mon, Sep 24, 2012 at 12:50:12PM +0200, SF Markus Elfring
<elfr...@users.sourceforge.net> wrote:
> > And why would that not be safe?
> It is not guaranteed that it can be modified in an atomic way.
Ok, I herewith guarantee it to you. Moreover, atomicity is not required for
this variable for accesses to it to be race-free (but libev users might rely
on this, which is why libev makes it work).
> > Nothing suggests otherwise.
> Race conditions are hard to diagnose, aren't they?
Sure, but nothing suggests that there is a race either. Races and
non-atomic accesses are also quite different beasts, and don't follow from
each other.
> Is it also a software challenge to agree on proper solutions for this
> implementation detail?
No, "agreeing" is a wetware challenge.
> SIG31-C:
> 'sig_atomic_t ... It is important to note that the behavior of a program that
> accesses an object of any other type from a signal handler is undefined.'
I don't know where this originates, but neither ISO-C nor POSIX have any
such limitation. It is either quoted fully out of it's (required) context
or obvious bullshit.
For example, objects of automatic storage are always completely safe (per
ISO-C). errno in POSIX must be async-signal-safe too (and is of type int),
and there are many more safe cases.
And as I write for the third time now, libev isn't bound by ISO-C
or even POSIX. It cannot be as it relies on numerous extensions of
the implementation (such as select (not in ISO-C) or epoll (not in
POSIX)). The only hard requirement on it is to actually work and follow
its own guarantees.
It would be helpful if you could acknowledge this instead of repeating
statements that are either provably wrong or do not apply to the code in
question.
> Common Weakness Enumeration 364:
> 'There are several known behaviors related to signal handlers that have
> received
> the label of "signal handler race condition":
> * Shared state (e.g. global data or static variables) that are accessible to
> both a signal handler and "regular" code'
That's true, but from the fact that some of these can be racy does not
follow that all of these are racy. For example, if there are no concurrent
accesses there is no race.
If the "Common Weakness Enumeration 364" makes the claim that this is
always a race condition then it's simply wrong. Does it or did you quote
out of context?
--
The choice of a Deliantra, the free code+content MORPG
-----==- _GNU_ http://www.deliantra.net
----==-- _ generation
---==---(_)__ __ ____ __ Marc Lehmann
--==---/ / _ \/ // /\ \/ / schm...@schmorp.de
-=====/_/_//_/\_,_/ /_/\_\
_______________________________________________
libev mailing list
libev@lists.schmorp.de
http://lists.schmorp.de/cgi-bin/mailman/listinfo/libev
