event_base_free(NULL) means "free the current event base".
Previously, it would assert if there was no 'current' base. Now it
just warns and returns.
Reported by Gilad Benjamini
Previously, we did stuff like
if (!lock)
EVTHREAD_ALLOC_LOCK(lock,0);
for the evsig base global lock, the arc4random lock, and the debug_map
lock. But that's potentially racy! Instead, we move the
responisiblity for global lock initialization to the functions where
we set up the lock callbacks.
(Rationale: We already require that you set up the locking callbacks
before you create any event_base, and that you do so exatly once.)
For now, we'll only check for gettimeofday jumps once every 5 seconds.
Let's see how that works.
This reverts commit 5209fadfd07af3f3379ac607582c37933b33e044.
We don't need to wake up the base when rescheduling the timeout that
will expire first: the base will already wake up, see that nothing is
ready, and go back to sleep.
Merely getting an internal notification event from having an event
added or deleted from another thread should not cause
event_base_loop(base, EVLOOP_ONCE) to exit; previously, it did.
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.
The trick here is that if we already told the base to wake up, and it
hasn't woken up yet, we don't need to tell it to wake up again. This
should help lots with inherently multithreaded code like IOCP.
If threads queue callbacks while event_process_deferred_callbacks is
running, the loop may spin long enough to significantly skew timers.
A unit test stressing this behavior is also in this commit.
- Increment reference count of bufferevents before initiating overlapped
operations to prevent the destructor from being called while operations
are pending. The only portable way of canceling overlapped ops is to
close the socket.
- Translate error codes to WSA* codes.
- Better handling of errors.
- Add an interface to add and del "virtual" events. Because IOCP
bufferevents don't register any events with the base, the event loop
has no way of knowing they exist. This causes the loop to terminate
prematurely. event_base_{add,del}_virtual increment/decrement base's
event count so the loop runs while there are any enabled IOCP
bufferevents.
After a fork, you want subthreads to wake up the event_base in the
child process, not to have the child process and the main process
fight over who wakes up whom.
Related to a problem found by Nicholas Marriott while debugging
3048812.
Nicholas Marriott identifies an issue where a signal socketpair
doesn't get recreated if the event backend doesn't set event_reinit.
See bug 3048812
There may be a similar issue with respect to th_notify_fd
Avi Bab correctly noted as bug 3044479 the fact that any thread
blocking on current_event_lock will do so while holding
th_base_lock, making it impossible for the currently running event's
callback to call any other functions that require th_base_lock.
This patch switches the current_event_lock code to instead use a
condition variable that we wait on if we're trying to mess with
a currently-executing event, and that we signal when we're done
executing a callback if anybody is waiting on it.
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).
There was previously no lock protecting the signal event's
ev_ncalls/ev_pncalls fields, which were accessed by all of
event_signal_closure, event_add_internal, event_del_internal, and
event_active_nolock. This patch fixes this race by using the
current_event_lock in the same way it's used to prevent
event_del_internal from touching an event that's currently running.
The problem was that the thread doing the notification could block on
write in evthread_notify_base_default while holding the th_base_lock.
The main thread would never drain th_notify_fd[0], since it would need
th_base_lock to actually trigger events.
