Re: [Libevent-users] Sigprocmask vs pthread_sigprocmask

2007-02-22 Thread Niels Provos

Do you have an addition to the regression test that would allow me to
verify that the new code works as intended?   If not, it would be most
appreciated :-)

Niels.

On 2/22/07, Scott Lamb [EMAIL PROTECTED] wrote:


On Feb 21, 2007, at 1:29 AM, William Ahern wrote:

 On Wed, Feb 21, 2007 at 03:44:58AM -0500, Nick Mathewson wrote:
 snip
 libevent, I'm going to use pthreads; use pthread_sigmask()
 instead of
 sigprocmask().  I don't know what that interface should be, but the
 corresponding code should be pretty simple to write.

 Probably should be a [global] function pointer, since an autoconf
 check
 doesn't address the linking issue.

What about just never using sigprocmask() or pthread_sigmask()? The
patch I sent to the list a while back fixes two bugs:

* prevents Anton Povarov's reported race in which a signal delivered
quickly after event_signal_add() isn't handled correctly
* avoids sigprocmask(), which is not pthread-safe.

There are still several caveats with threads. Ignoring the complex
idea of sharing an event_base between threads (need still has to be
proven...I've been way too busy with other things to run the
benchmarks I've been wanting to), these ones remain:

2. If you forget event_base_set on an event, it's associated with the
latest base created. This will probably work most of the time. It'd
be much less confusing if it consistently broke.

3. Each new base created leaks the existing ev_signal_pair descriptors.

4. Signals are delivered to whatever event loop happens to see them
first.

6. You can't destroy an event_base.

My old patch and notes are below.

This patch does not get rid of ncalls, which I'm also thinking of
doing, as I mentioned in an earlier message to the list.

devpoll.c  |   15 +++
epoll.c|   15 +++
evport.c   |   17 +++--
evsignal.h |8 ++
poll.c |   15 +++
select.c   |   14 +++---
signal.c   |   74 +++
+-
test/regress.c |   32 
8 files changed, 76 insertions(+), 114 deletions(-)

There's one subtlety to it. With my change, evsignal_process() runs
with signals unblocked, so timing is critical. The original code is
then racy:

 TAILQ_FOREACH(ev, signalqueue, ev_signal_next) {
 ncalls = evsigcaught[EVENT_SIGNAL(ev)];-- 
point A
 if (ncalls) {
 if (!(ev-ev_events  EV_PERSIST))
 event_del(ev);
 event_active(ev, EV_SIGNAL, ncalls);
 }
 }

 memset(evsigcaught, 0, sizeof(evsigcaught));   -- point B
 evsignal_caught = 0;   -- point C

For any signal that is not already pending (ncalls == 0 when reaching
its point A), if it arrives between then and its ncalls being cleared
in point B, it will be lost. If it arrives after then but before
evsignal_caught in point C, it will be arbitrarily delayed (until
another signal comes along to set   evsignal_caught).

I solved this by

* moving the evsignal_caught to before checking the individual
signals for delivery (but after evsignal_caught is checked itself, in
a different function).
* setting evsigcaught[x] = 0 only when we are setting that signal
active.

--
Scott Lamb http://www.slamb.org/




___
Libevent-users mailing list
Libevent-users@monkey.org
http://monkey.org/mailman/listinfo/libevent-users




___
Libevent-users mailing list
Libevent-users@monkey.org
http://monkey.org/mailman/listinfo/libevent-users


Re: [Libevent-users] Sigprocmask vs pthread_sigprocmask

2007-02-22 Thread Scott Lamb


On Feb 22, 2007, at 6:32 PM, Niels Provos wrote:


Do you have an addition to the regression test that would allow me to
verify that the new code works as intended?   If not, it would be most
appreciated :-)


There is one that verifies the quickly received signal case. Are you  
talking about the race condition I describe? In that case, no...I  
could try something that pounds on it in a loop for a bit or  
something, if you like.


Also realized I sent an older version of the patch just now...newer  
one attached. (Why can I never send a patch to a mailing list  
correctly the first time? It's a bizarre handicap.)




event-signal.patch
Description: Binary data
___
Libevent-users mailing list
Libevent-users@monkey.org
http://monkey.org/mailman/listinfo/libevent-users


[Libevent-users] Sigprocmask vs pthread_sigprocmask

2007-02-21 Thread Nick Mathewson
Hi, all.  There's been a recent exchange on the Tor development list
about the intersection of signals with pthreads with libevent.  Both
posts are (I hope) concise, so I'll link to them here:
  http://archives.seul.org/or/dev/Feb-2007/msg00028.html
  http://archives.seul.org/or/dev/Feb-2007/msg00030.html

In summary: when pthreads are in use, it's wrong to call
sigprocmask(), and right to call its identical cousin,
pthread_sigmask().  This isn't just a cosmetic issue; it can cause
real bugs with signal delivery.  Right now, libevent only calls
sigprocmask.  It would be good if there were some way to tell
libevent, I'm going to use pthreads; use pthread_sigmask() instead of
sigprocmask().  I don't know what that interface should be, but the
corresponding code should be pretty simple to write.

yrs,
-- 
Nick Mathewson


pgpjhJl3Tsp4y.pgp
Description: PGP signature
___
Libevent-users mailing list
Libevent-users@monkey.org
http://monkey.org/mailman/listinfo/libevent-users