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.
To be fair, when char can be signed, if toupper doesn't take negative
characters, toupper(char) is a very bad idea. So let's just use the
nice safe EVUTIL_TOUPPER instead. (It explicitly only upcases ASCII,
but we only use it for identifiers that we know to be ASCII anyway).
On all the backends on this little mac laptop, that behavior is to
report a remote socket close as both EV_READ and EV_WRITE.
Historically, we had problem for some of these behaviors on some
backends, so let's make sure that such behaviors don't come back.
The "current_base" symbol was never actually declared in an exported
header; it's hideously deprecated, and it was the one remaining
exported symbol (fwict) that was prefixed with neither ev nor
bufferevent nor _ev nor _bufferevent.
codesearch.google.com turns up no actual attempts to use our
current_base from outside libevent.
The EVUTIL_CLOSESOCKET() macro required you to include unistd.h in your
source for POSIX. We might as well turn it into a function: an extra
function call is going to be cheap in comparison with the system call.
We retain the EVUTIL_CLOSESOCKET() macro as an alias for the new
evutil_closesocket() function.
(commit message from email by Nick and Sebastian)
Calling event_base_loop on a base from inside a callback invoked by
that same base, or from two threads at once, has long been a way to
get exceedingly hard-to-diagnose errors. This patch adds code to
detect such reentrant invocatinos, and exit quickly with a warning
that should explain what went wrong.
This is mainly intended to ensure that we don't get hung up on
the 64-handle limit that lots of O(n) Windows functions (but FWICT
not select) like to enforce.
Remeber, win32 has a socket type that's actually a handle, so if
there's a chance that code is run on win32, we can't use "int" as the
socket type.
This isn't a blind search-and-replace: sometimes an fd is really in
fact for a file, and not a socket at all.
Previously, we assumed that we would have setenv/unsetenv everywhere
but WIN32, where we could fake them with putenv. This isn't so: some
other non-windows systems lack setenv/unsetenv, and some of them lack
putenv too.
The first part of the solution, then, is to detect setenv/unsetenv/
putenv from configure.in, and to fake setenv/unsetenv with putenv
whenever we have the latter but not one of the former.
But what should we do when we don't even have putenv? We could do
elaborate tricks to manipulate the environ pointer, but since we're
only doing this for the unit tests, let's just skip the one test in
question that uses setenv/unsetenv.
Libevent's current timeout code is relatively optimized for the
randomly scattered timeout case, where events are added with their
timeouts in no particular order. We add and remove timeouts with
O(lg n) behavior.
Frequently, however, an application will want to have many timeouts
of the same value. For example, we might have 1000 bufferevents,
each with a 2 second timeout on reading or writing. If we knew this
were always the case, we could just put timeouts in a queue and get
O(1) add and remove behavior. Of course, a queue would give O(n)
performance for a scattered timeout pattern, so we don't want to
just switch the implementation.
This patch gives the user the ability to explicitly tag certain
timeout values as being "very common". These timeout values have a
cookie encoded in the high bits of their tv_usec field to indicate
which queue they belong on. The queues themselves are each
triggered by an entry in the minheap.
See the regress_main.c code for an example use.
svn:r1517
I've gone through everything that it declared to see where it was used,
and it seems that we probably don't need it anywhere.
Here's what it declared, and why I think we're okay dropping it.
o struct timeval {}
(Used all over, and we can't really get away with declaring it ourselves;
we need the same definition the system uses. If we can't find struct
timeval, we're pretty much sunk.)
o struct timespec {}
(Used in event.c, evdns.c, kqueue.c, evport.c. Of these,
kqueue.c and event.c include sys/_time.h. event.c conditions its use on
_EVENT_HAVE_CLOCK_GETTIME, and kqueue() only works if timespec is defined.)
o TIMEVAL_TO_TIMESPEC
(Used in kqueue.c, but every place with kqueue has sys/time.h)
o struct timezone {}
(event2/util.h has a forward declaration; only evutil.c references it and
doesn't look at its contents.)
o timerclear, timerisset, timercmp, timeradd, timersub
(Everything now uses the evutil_timer* variants.)
o ITIMER_REAL, ITIMER_VIRTUAL, ITIMER_PROF, struct itemerval
(These are only used in test/regress.c, which does not include _time.h)
o CLOCK_REALTIME
(Only used in evdns.c, which does not include _time.h)
o TIMESPEC_TO_TIMEVAL
o DST_*
o timespecclear, timespecisset, timespeccmp, timespecadd, timespecsub
o struct clockinfo {}
o CLOCK_VIRTUAL, CLOCK_PROF
o TIMER_RELTIME, TIMER_ABSTIME
(unused)
svn:r1494
This is a glass-box test to get more coverage on the event loop
backends. We've run into bugs here before with fencepost errors, and
it turns out that none of our unit tests had enough events to
exercise the resize code.
Most of the backends have some kind of logic that resizes an array
when:
- The highest fd is too high
- The number of events added since the last iteration of the loop
is too high
- The number of active events is too high.
This test hits all 3 cases, and increases coverage in select.c by 7%,
in poll by 1%, and in kqueue by 9%.
svn:r1482
Previously, each of the three make-an-event-base functions would exit
under different, weird circumstances, but return NULL on others.
- All three would exit on OOM sometimes.
- event_base_new() and event_init() would die if all backends were
disabled.
- None of them would die if the socketpair() call failed.
Now, only event_init() exits on failure, and it exits on every kind of
failure. event_base_new() and event_base_new_with_config() never do.
svn:r1472
Basically, we suppress the notification when an event is added or deleted
and:
- The event has no fd, or there is no change in whether we are
reading/writing on the event's fd.
- The event has no timeout, or adding the event did not make the earliest
timeout become earlier.
This should be a big efficiency win in applications with multiple threads and
lots of timeouts.
svn:r1439
The problem was introduced when we changed the semantics of
get_supported_methods() to reflect all the methods that exist.
Previously, it had not returned methods disabled from the environment,
but the test didn't know that.
svn:r1379
They're now called evtag_encode_int(64). The old names are available
as macros in event2/tag_compat.h.
Also, add unit tests for encode/decode_int64.
svn:r1365
