Since we're no longer writing directly to it from add/del, we don't
need to worry about it changing as kq_dispatch releases the lock. We
would make it a local variable, except that we wouldn't want to malloc
and free it all the time.
This fixes a bug in kqueue identified by Charles Kerr and various
Transmission users, where adding and deleting an event in succession
would make the event get reported, even if we didn't actually want to
see it.
Of course, this also makes the array of changes passed to kevent
smaller, which could help performance.
This is necessary or useful for a few reasons:
1) Sometimes applications will add and delete the same event more
than once between calls to dispatch. Processing these changes
immediately is needless, and potentially expensive (especially
if we're on a system that makes one syscall per changed event).
Yes, this actually happens in practice for nonpathological
code, such as in cases where the user's callback conditionally
re-adds a non-persistent event, or where draining a buffer
turns off writing and invokes a user callback which adds more
data which in turn re-enabled writing.
2) Sometimes we can coalesce multiple changes on the same fd into
a single syscall if we know about them in advance. For
example, epoll can do an add and a delete at the same time, but
only if we have found out about both of them before we tell
epoll.
3) Sometimes adding an event that we immediately delete can cause
unintended consequences: in kqueue, this makes pending events
get reported spuriously.
This was as simple as using bufferevent_connect_hostname instead of
calling connect() ourself, which already knows how to use an
evdns_base if it gets one.
Untangling the bind code might be a little trickier.
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
This is harder than it might initially seem, since the proper filename
depends on what the admin has decided to call the windows system directory,
which for all we know might be Q:\tralfamidore\slartibartfast. And of course,
this being windows, there are twelve ways to do it, where you can pick a
nice one or a portable one, but not a really nice portable one.
The regular blocking evutil_getaddrinfo() already supported /etc/hosts
by falling back to getaddrinfo() or gethostbyname(). But
evdns_getaddrinfo() had no such facility. Now it does.
The data structure here isn't very clever. I guess people with huge
/etc/hosts files will either need to get out of the 1980s, or submit a
patch to this code so that it uses a hashtable instead of a linked
list.
Includes basic unit tests.
Apparently some newer versions of mingw provide a fake pthreads api to
let applications work even if they don't know about windows threading.
That's nice, but we aren't one of those.
In many places throughout the code, we called _bufferevent_run_eventcb
without checking whether the eventcb was actually set. This would
work fine when the bufferevent's callbacks were deferred, but
otherwise the code would segfault. Strangely, we always remembered to
check before calling the _bufferevent_run_{read,write}cb functions.
To prevent similar errors in the future, all of
_buferevent_run_{read,write,event}cb now check to make sure the
callback is actually set before invoking or deferring the callback.
This patch also removes the now-redundant checks for {read,write}cb.
By default, the test.sh script still suppresses the output of all the
tests it invokes. Now, however, you can have that output written to
a file specified in the TEST_OUTPUT_FILE shell variable.
When we decide that a nameserver is down, we stop sending queries to
it, except to periodically probe it to see if it has come back up.
Our previous probe sechedule was an ad-hoc and hard-wired "10 seconds,
one minute, 5 minues, 15 minutes, 1 hour, 1 hour, 1 hour...". There
was nothing wrong with having it be ad-hoc, but making it hard-wired
served no good purpose.
Now the user can set the initial timeout via a new
"initial-probe-timeout:" option; future timeouts back off by a factor
of 3 on every failure to a maximum of 1 hour.
As a side-benefit, this lets us cut the runtime of the dns/retry test
from about 40 seconds to about 3 seconds. Faster unit tests are
always a good thing.
This is not part of the regression tests, since running it necessarily
takes a while. There is a new test-ratelim test; run it with '-h'
for an argument to see its options.
The fairness algorithms are not the best, not every bufferevent type
is supported, and some of the locking tricks here are simply absurd.
Still, this code should be a good first step.
