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
This makes our interfaces usable from C++, which doesn't believe
you can say "bufferevent_socket_nase(base, -1,
BEV_OPT_CLOSE_ON_FREE|BEV_OPT_DEFER_CALLBACKS)" but which instead
would demand "static_cast<bufferevent_options>(BEV_OPT_CLOSE_ON_FREE|
BEV_OPT_DEFER_CALLBACKS))" for the last argument.
Diagnosis and patch from Chris Davis.
svn:r1456
This is harder than it sounds, since we need to make sure to
release the lock around the key call to the kernel (e.g.,
select, epoll_wait, kevent), AND we need to make sure that
none of the fields that are used in that call are touched by
anything that might be running concurrently in another
thread. I managed to do this pretty well for everything but
poll(). With poll, I needed to introduce a copy of the
event_set structure.
This patch also fixes a bug in win32.c where we called
realloc() instead of mm_realloc().
svn:r1450
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
Previously, events that were disabled using EVENT_NO* were left out of
event_get_supported_methods(). This was wrong, broke unit tests
(under some circumstances) and left the user with no good way to tell
which methods were actually compiled in.
Fixes bug 2821015.
svn:r1344
This gives you the property that once you have called event_del(E),
you know that E is no longer running or pending or active at all, and
so it is safe to delete the resource used by E's callback.
svn:r1341
A 'deferred callback' is just a function that we've queued in the
event base. This ability is needed for some mt stuff, and for complex
callback chains. For internal use only.
svn:r1150
This is exceptionally important with multithreaded stuff, where we use
an event to notify the base that other events have been made active.
If the activated events have a prioirty number greater than that of the
notification event, it will starve them, and that's no good.
svn:r1149
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
