The previous evbuffer_expand was not only incorrect; it was
inefficient too. On all questions of time vs memory tradeoffs, it
chose to burn time in order to avoid wasting memory. The new code
tries to be a little more balanced: it only resizes an existing chain
when doing so doesn't require too much copying, and when failing to do
so would waste a lot of the chain's space.
This patch also rewrites evbuffer_chain_insert to work properly with
last_with_datap, and adds a few convenience functions to buffer.c.
To implement evbuffer_expand() properly, you need to be able to
replace the last chunk that has data, which means that we need to keep
track of the the next pointer pointing to the last_with_data chunk,
not the last_with_data chunk itself.
Calling event_base_loop on a base from inside a callback invoked by
that same base, or from two threads at once, has long been a way to
get exceedingly hard-to-diagnose errors. This patch adds code to
detect such reentrant invocatinos, and exit quickly with a warning
that should explain what went wrong.
This is mainly intended to ensure that we don't get hung up on
the 64-handle limit that lots of O(n) Windows functions (but FWICT
not select) like to enforce.
We were using the same bufferevent as the child of two filtering parents,
orphaning another. This made one get freed twice, and the other not at all.
Possible fix for bug 2963306 spotted by Doug Cuthbertson.
This actually makes some of the code a lot simpler. The only
ones that actually used previous_to_last for anything were reserving
and committing space.
This is the first patch in a series to replace previous_to_last with
last_with_data. Currently, we can only use two partially empty chains
at the end of an evbuffer, so if we have one with 511 bytes free, and
another with 512 bytes free, and we try to do a 1024 byte read, we
can't just stick another chain on the end: we need to reallocate the
last one. That's stupid and inefficient.
Instead, this patch adds a last_with_data pointer to eventually
replace previous_to_last. Instead of pointing to the penultimated
chain (if any) as previous_to_last does, last_with_data points to the
last chain that has any data in it, if any. If all chains are empty,
last_with_data points to the first chain. If there are no chains,
last_with_data is NULL.
The next step is to start using last_with_data everywhere that we
currently use previous_to_last. When that's done, we can remove
previous_to_last and the code that maintains it.
Remeber, win32 has a socket type that's actually a handle, so if
there's a chance that code is run on win32, we can't use "int" as the
socket type.
This isn't a blind search-and-replace: sometimes an fd is really in
fact for a file, and not a socket at all.
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.
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.
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.
Previously, we assumed that we would have setenv/unsetenv everywhere
but WIN32, where we could fake them with putenv. This isn't so: some
other non-windows systems lack setenv/unsetenv, and some of them lack
putenv too.
The first part of the solution, then, is to detect setenv/unsetenv/
putenv from configure.in, and to fake setenv/unsetenv with putenv
whenever we have the latter but not one of the former.
But what should we do when we don't even have putenv? We could do
elaborate tricks to manipulate the environ pointer, but since we're
only doing this for the unit tests, let's just skip the one test in
question that uses setenv/unsetenv.
If the user sets a bind address to use for nameservers, and a
nameserver happens to be on 127.0.0.1, the nameserver will generally
fail. This patch alters this behavior so that the bind address is
only applied when the nameserver is on a non-loopback address.
Some systems have a version of /bin/sh whose builtin echo doesn't
support the -n option used in test/test.sh. /bin/echo, however,
usually does. This patch makes us use /bin/echo for echo -n whenever
it is present.
Also, our use of echo -n really only made sense when suppressing all
test output. Since test output isn't suppressed when logging to a
file, this pach makes us stop using echo -n when logging to a file.
This is a partial forward-port from 4fd2dd9d83a000b6. There's no need
to forward-port the bugfix, since the test passes with http.c as-is.
I believe we fixed this while we were porting evhttp to bufferevent.
--nickm
