Since we're computing the time after each callback, we might as well
update the time cache (if we're using it) and use monotonic time (if
we've got that).
Conflicts:
event.c
The conflicts were with the 21_faster_timeout_adj branch, which
added a "reinsert" function that needed to get renamed to
"reinsert_timeout". Also, some of the code that 21_split_functions
changes got removed by 21_faster_timeout_adj.
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.
