| Commit message (Collapse) | Author | Age | Files | Lines |
|---|
| | |
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Jason Toffaletti discovered with helgrind that our signal handler was
messing with evsig_base, which can be set from lots of places in the
code. Ordinarly, we'd just stick a lock on it, except that it is
illegal (and genuinely error-prone) to call pthread_mutex_acquire()
from inside a signal handler.
The solution is to only store the fd we write to in a static variable,
write the signal number to the fd, and put evsig_cb in charge of
activating signal events.
I have no idea how we'll cope if we want to enable this to handle
siginfo (where available) in the future.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Also, fix a couple of race conditions in signal.c
When using the signal.c signal backend, Libevent currently only allows
one event_base to actually receive signals at a time. (This has been
the behavior since at least 1.4 and probably much earlier.) Now, we
detect and warn if you're likely to be racing about which signal goes
to which thread.
We also add a lock to control modifications of the evsig_base field,
to avoid race conditions like those found by Jason Toffaletti.
Also, more comments. Comments are good.
|
| | |
|
| |
|
|
|
|
|
|
|
|
|
|
|
| |
Some win32 systems (mostly those using Kaspersky, it would seem)
prevent us from faking socketpair(). This makes our signal
notification code just not work. Our response since 1.4 has been to
assert. For users who would rather work without signals than not work
at all, this has been a regression from 1.3e.
This patch makes adding signal events fail in this case; there's no
reason to kill the whole process.
svn:r1303
|
| |
|
|
| |
svn:r1276
|
| |
|
|
|
|
|
|
|
| |
a) this is 2009
b) niels and nick have been comaintainers for a while
c) saying "all rights reserved" when you then go on to explicitly
disclaim some rights is sheer cargo-cultism.
svn:r1065
|
| |
|
|
| |
svn:r1064
|
|
|
svn:r1000
|
