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.
- Prevent evbuffer_{add,prepend}_buffer from moving read-pinned chains.
- Fix evbuffer_drain to handle read-pinned chains better.
- Raise the limit on WSABUFs from two to MAX_WSABUFS for overlapped reads.
This reverts commit fab50488fcb741884ccdfa7b83643eac3e5c9cbf.
The function was, on reflection, not important enough to break the feature
freeze, since it's trivial to build on your own.
Remember that in a fit of ANSI C compliance, Microsoft decided to
screw portability by renaming basically all the functions in unistd.h to
get prefixed with an understore.
For some reason, mingw didn't seem to mind, but at least some people's
compilers did: see bug 3044490.
I swear, they must have half a dozen different calling conventions.
(goes to check)
Holy crud. They actually do. There's __cdecl, __stdcall, __fastcall,
"thiscall", "naked" and the obsolete "__pascal", "__fortran", and
"__syscall". And don't forget WINAPI and __far.
Anyways, this should fix 3044488 if I got it right.
The evhttp_parse_query API is a bit misdesigned; all the other
evkeyvalq stuff is abstract and lets you get away with having a header
stub, but evhttp_parse_query seems to require that you instantiate an
empty evkeyvalq of your own.
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.
This requires us to have a separate implementation of the lock macros
that indirects to a set of functions. Fortunately, this isn't too
hard to do.
This may be a fix for bug 3042969, where our openssl dll and our
libevent dll each got their own version of the thread stuff.
The do ... while loop in our wait code could spin while waiting
because the event object wasn't reset until there were no longer any
events waiting to be woken up. We also want to reset the event object
if the count of events to wake up reaches zero.
Found by Chris Davis. Fixes bug 3053358.
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
Apparently, in our configure.in check for a working kqueue, we were
leaving some fields unset that seemed to irritate 64-bit kqueue a lot.
Found by Christopher Layne
Gilad Benjamini noted that we check the error code for deleting a
write-timeout event twice, and the read timeout not at all. This
shouldn't be a bit problem, since it's really hard for a delete to
fail on a timeout-only event, but it's worth fixing.
Fixes bug 3046787
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.
The interface from the user's POV is similar to the locking
implementation: either provide a structure full of function
pointers, or just call evthread_use_*_threads() and everything will
be okay.
The internal interface is meant to vaguely resemble pthread_cond_*,
which Windows people will better recognize as *ConditionVariable*.
Though the C standards allow it, it's apparently possible to get MSVC
upset by saying "struct { int field; } (declarator);" instead of
"struct {int field; } declarator;", so let's just not do that.
Bugfix for 3044492
(commit msg by nickm)
As a generated file, it shouldn't get included in our source
distribution. Apparently there is an automake incant for this:
nobase_ even stacks with nodist_ .
