It looks like I accidentally removed most of WIN32-Code/event-config.h
when I was bumping the version. Fortunately, this happened when I
bumped to 2.0.4-alpha-dev rather than when I bumped to 2.0.4-alpha. :)
This patch restores the deleted parts of WIN32-Code/event-config.h
There should be no need to call be_socket_enable: that does an
event_add(). What we really want to do is event_active(), to make
sure that the writecb is executed.
Also, there was one "} if () {" that was missing an else.
I've noted that the return value for evutil_socket_connect() is
getting screwy, but since that isn't an exported function, we can fix
it whenever.
The different bufferevent implementations had different behavior for
their timeouts. Some of them kept re-triggering the timeouts
indefinitely; some disabled the event immediately the first time a
timeout triggered. Some of them made the timeouts only count when
the bufferevent was actively trying to read or write; some did not.
The new behavior is modeled after old socket bufferevents, since
they were here first and their behavior is relatively sane.
Basically, each timeout disables the bufferevent's corresponding
read or write operation when it fires. Timeouts are stopped
whenever we suspend writing or reading, and reset whenever we
unsuspend writing or reading. Calling bufferevent_enable resets a
timeout, as does changing the timeout value.
When we fixed persistent timeouts to make them reset themselves
based on the previous scheduled time rather than the current
time... we made them do so regardless of whether the event was
triggering because of a timeout or not!
This was of course bogus. When a _timeout_ triggers, we should
schedule the event for N seconds based on the last
_schedule_ time... but when IO triggers, we should reset the
timeout for N seconds after now.
I found these by adding an EVENT_BASE_ASSERT_LOCKED() call to most
of the functions in event.c that can only be called while holding
the lock.
event_reinit() never grabbed the lock, but it needed to.
event_persist_closure accessed the base to call event_add_internal()
and gettime() when its caller had already dropped the lock.
event_pending() called gettime() without grabbing the lock.
This should end the family of bugs where we call bufferevent_free()
while a pending callback is holding a reference on the bufferevent,
and the callback tries to invoke the user callbacks before it releases
its own final reference.
This means that bufferevent_decref() is now a separate function from
bufferevent_free().
When we're doing a lookup in preparation for doing a connect, we
might have an unconnected socket on hand, and mustn't actually do
any reading or writing with it.
On Windows, getpid() is _getpid(), and requires that we first include
<process.h>. arc4random.c previously didn't know that.
Actually, I question whether arc4random needs to do its getpid() tricks
on Windows. They exist only so that we remember to re-seed the ARC4
cipher whenever we fork... but Windows has no fork(), so I think we're
in the clear.
This fixes a bug turned up with the http unit tests, where we create
the evhttp object using an implicit (NULL) event_base. This failed
pretty badly when we tried to use IOCP-based listeners. We could
hunt for the current base from inside listener.c in the future, or
get the iocp base some other way, but for now this is probably the safest
solution.
Previously we were using InitializeCriticalSection, which creates a
lock that blocks immediately on contention and waits to be
rescheduled. This is inefficient; it's better to wait for a little
while before telling the US to reschedule us, in case the lock becomes
available again really soon (since most locks mostly do).
Good pthreads implementations do this automatically. On Windows,
though, we need to call this magic function, and we need to pick the
spin count ourselves.
Some initializers (in evbuffer_read and evbuffer_commit) were reading
the last and/or previous_to_last fields without grabbing the evbuffer
lock.
This may fix a hard-to-trigger race condition or two.
We've changed a couple of APIs introduced in 2.0.1-alpha, so it
behooves us to give high-needs apps (like Tor) a way to tell we've
done this.
Sensible apps will just say "is it 2.0.3-alpha or 2.0.4-alpha" and
ignore the existence of 2.0.3-alpha-dev, which is just as it should
be.
Previously, evdns was at the mercy of the user for providing a good
entropy source; without one, it would be vulnerable to various
active attacks.
This patch adds a port of OpenBSD's arc4random() calls to Libevent
[port by Chris Davis], and wraps it up a little bit so we can use it
more safely.
The 'flags' argument made sense when passed to
evdns_(base_)?parse_resolv_conf when it said which parts of the
resolv.conf file to obey. But for evdns_set_option(), it was really
silly, since you wouldn't be calling evdns_set_option() unless you
actually wanted to set the option. Its meaning was basically, "set
this to DNS_OPTIONS_ALL unless you want a funny surprise."
evdns_base_set_option was new in 2.0.1-alpha, so we aren't committed
to keeping it source-compatible.
