If we ran out of memory in evhttp_uriencode when allocating the
output buffer, we would neglect to call evbuffer_free() on our
temporary buffer. Now we always free the temporary buffer.
Fixes sourceforge issue 3539887. Thanks to Andrew Cox for reporting
this one.
This is necessary for making some thread libraries work with
event.c, and might get better performance with others.
The biggest change required here was that we needed to make some
internal code that had previously called event_add and event_del
call the nolock variants.
The original code needlessly called open in its two- or three-
argument format depending on the O_CREAT flag; this should not be
needed.
The code also leaked an fd if fcntl() failed.
Reported by Dave Hart.
(Tweaked by nickm: Fix up the arcr4andom_buf OSX hack so that the
fallback case isn't compiled into the code when we have
arc4random_buf() and we are not on OSX. Also add a comment
explaining what's up.)
Back when deferred_cb stuff had its own queue, the queue was always
executed, but we never ran more than 16 callbacks per iteration.
That made for two problems:
1: Because deferred_cb stuff would always run, and had no priority,
it could cause priority inversion.
2: It doesn't respect the max_dispatch_interval code.
Then, when I refactored deferred_cb to be a special case of
event_callback, that solved the above issues, but made for two more
issues:
3: Because deferred_cb stuff would always get the default priority,
it could could low-priority bufferevents to get too much priority.
4: With code like bufferevent_pair, it's easy to get into a
situation where two deferreds keep adding one another, preventing
the event loop from ever actually scanning for more events.
This commit fixes the above by giving deferreds a better notion of
priorities, and by limiting the number of deferreds that can be
added to the _current_ loop iteration's active queues. (Extra
deferreds are put into the active_later state.)
That isn't an all-purpose priority inversion solution, of course: for
that, you may need to mess around with max_dispatch_interval.
