2. Would it eventually need to be protected by a mutex (from the
multi-threading perspective)?
Using a mutex in a signal handler is neither conforming nor working in
practise, so far worse than the current approach.
I find it interesting that the statements ECB_MEMORY_FENCE_ACQUIRE and
Will any lock-free approaches become feasible for comparison and selection
by a
build configuration?
Libev's algorithm is already lock-free (and has to be) - what do you want
to compare it with?
How do you think about information from an article like Signal-Safe Locks?
On Tue, Sep 25, 2012 at 09:20:50AM +0200, SF Markus Elfring
elfr...@users.sourceforge.net wrote:
How do you think about information from an article like Signal-Safe Locks?
http://locklessinc.com/articles/signalsafe_locks/
According to the article, it's not applicable to libev and also doesn't
Can you elaborate on why not?
Yes, of course.
I find that the information ev_feed_signal ... safe to call this function ...,
including signal handlers or random threads. is not satisfied by the current
implementation at the moment.
Reasons:
1. A shared array is used there.
2. Would it
1. A shared array is used there.
And why would that not be safe?
It is not guaranteed that it can be modified in an atomic way.
Nothing suggests otherwise.
Race conditions are hard to diagnose, aren't they?
Is it also a software challenge to agree on proper solutions for this
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
Hello,
I suggest to look at the implementation of the function ev_sighandler again.
http://cvs.schmorp.de/libev/ev.c?revision=1.448view=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-safe for
On Sun, Sep 23, 2012 at 03:51:36PM +0200, SF Markus Elfring
elfr...@users.sourceforge.net 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
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 07:40:59PM +0200, SF Markus Elfring
elfr...@users.sourceforge.net 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
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 02:43:18PM -0700, Colin McCabe cmcc...@alumni.cmu.edu
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
12 matches
Mail list logo
