On Sun, Sep 23, 2012 at 02:43:18PM -0700, Colin McCabe
wrote:
> If you check the header file, you find that ev_feed_signal_event is
> writing to a variable of type EV_ATOMIC_T, which turns out to be a
> typedef for sig_atomic_t.
Actually, "volatile sig_atomic_t", unless overriden.
The variable
If you check the header file, you find that ev_feed_signal_event is
writing to a variable of type EV_ATOMIC_T, which turns out to be a
typedef for sig_atomic_t.
So it's "almost" standards-compliant, except for the fact that
technically the standard says you must use volatile, and libev uses
memory
On Sun, Sep 23, 2012 at 07:40:59PM +0200, SF Markus Elfring
wrote:
> The expectations from an information in the documentation like the following
> can
> not be completely satisfied at the moment.
Can you elaborate on why not?
> > As far as we know, the current method is already safe and robus
> So the real question is whether this is a bug or not, or in other words,
> does this break any of the guarantees that libev gives on any platform
> that libev is used on?
I would see it as an "open issue" (or more a bug) for a specific implementation
detail where I would like to recommend a few
On Sun, Sep 23, 2012 at 03:51:36PM +0200, SF Markus Elfring
wrote:
> It calls the function "ev_feed_signal" which works with the global array
> "signals". I find that the use of this data type is not async-signal-safe for
> a
> strictly conforming program.
libev is quite obviously not a strictl
Hello,
I suggest to look at the implementation of the function "ev_sighandler" again.
http://cvs.schmorp.de/libev/ev.c?revision=1.448&view=markup#l2029
It calls the function "ev_feed_signal" which works with the global array
"signals". I find that the use of this data type is not async-signal-saf
