It's a bad idea to have a read callback read a fixed amount; Instead,
we should drain it, or have some way to know that more data is
arrived. Not unsafe in this case, but let's not encourage people to
learn bad habits.
This commit also notes some other stuff to fix.
This test opens a server socket, and forks a child which connects to that
server socket many times. It sets a low number for the max open file limit
to catch any file descriptor leaks.
It would not work on Windows since it uses fork() to be able to create both the
server and the clients.
Now there are appropriate "for each event", "for each fd", and "for
each signal" helpers that they can use; this makes the code a bit
simpler, and far less duplicated.
This lets me turn back on the functions I disabled when removing
eventlist.
Additionally, check more lists for circularity in
event_base_assert_ok().
Add typedefs for the callback types.
Name fewer things "ctx".
Adds an implementation of Floyd's tortoise-and-hare algorithm to check
for circularity in TAILQs and LISTs, to avoid the abuse of flags that
event_base_assert_ok() was doing before.
Suggested by Dave Hart.
A listening socket can be enabled with the sockopt
TCP_DEFER_ACCEPT. This informs the kernel to not call the user-land
accept() until real data has been written to the socket.
A new flag LEV_OPT_DEFERRED_ACCEPT has been introduced to
automatically set this option. Optionally
evutil_make_tcp_listen_socket_deferred() can be called manually.
(Tweaked slightly by nickm.)
When a nameserver is down, we periodically try sending a "probe"
message to that nameserver to see if it has come back up. If a
nameserver comes up, we cancel any pending probe messages.
Cancelling a probe message while handling the probe's response would
result in a access-after-free or a double-free, so when we notice that
we're about to call a nameserver up because of having received a probe
from it, we need to check whether current response is the response
from the probe.
There was a case where we didn't to that, though: when the resolver
gave us an unusual error response to our request that it resolve
google.com. This is pretty rare, but apparently it can happen with
some weird cacheing nameservers -- the one on the mikrotik router, for
example. Without this patch, we would crash with a NULL pointer
derefernce.
Thanks to Hannes Sowa for finding this issue and helping me track it
down.
