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.
This patch fixes calls to the win32 api to explicitly call the char* versions
of the functions. This fixes build failures when libevent is built with the
UNICODE define.
when sending chunked requests via multiple calls to evhttp_send_reply_chunk,
the client may close the connection before the server is done sending. this
used to cause a crash.
we introduce a new function evhttp_request_get_connection() that allows the
server to determine if the request is still associated with a connection.
If it's not, evhttp_request_free() needs to be called explicitly or the user
can call evhttp_send_reply_end() which just frees the request, too.
We need these for Tor, and other projects probably need them too. Uses
include:
- Checking whether bandwidth is mostly-used, and only taking some
actions when there's plenty of bandwidth.
- Deducting some non-bufferevent activities from a rate-limit group.
It turns out that absolutely everything that was including
windows.h was doing so needlessly; our headers don't need it,
so we should just include winsock2.h (since that's where
struct timeval is defined).
Pre-2.0 code will use the old headers, which include windows.h
for them, so we aren't breaking source compatibility with 1.4.
This solves the bug where we were leaving WIN32_LEAN_AND_MEAN
defined, in roughly the same way that buying an automobile
solves the question of what to give your coachman for boxing
day.
This was never supposed to be an exposed API, so its name should have been
more like _EVUTIL_CHECK_FMT. But it was only used in one place, so let's
just eliminate it.
These are old aliases for event_get_fd and event_get_signal, and they
haven't been the preferred way of doing things since 2.0.1-alpha.
For a while, we made them use struct event if it was included, but call
event_get_(fd|signal) if it wasn't. This was entirely too cute.
Apparently some 64-bit platforms don't like it when you say
unsigned hash(void *p)
{
return (unsigned)p;
}
even if you really honestly don't want the high bits of p. Perhaps
they will tolerate it if I say the equivalent of
unsigned hash(void *p)
{
return (unsigned) (uintptr_t) p;
}
We already emulate most of the other useful bits of stdint.h, and
we seem to have started to use uintptr_t in a few places throughout
the code. Let's make sure we can continue to do so even on backwards
platforms that don't do C99.
The logic that prevented the first loop in this function from being
infinite was rather confusing and hard to follow. It seems to confuse
some automatic analysis tools as well as me. Let's try to replace it
with something more comprehensible.
Our hash-table implementation stored a copy of the hash code in each
element. But as we were using it, all of our hash codes were
ridiculously easy to calculate: most of them were just a matter of a
load and a shift.
This patch lets ht-internal be built in either of two ways: one caches
the hash-code for each element, and one recalculates it each time it's
needed.
This patch also chooses a slightly better hash code for
event_debug_entry.
I don't expect that many users will be so religious about calling
unassign, but we need to be so that it's at least possible to use
debug mode without eating memory.
