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.
Those pointers were once used to maintain a complete list of
inserted IO and signal events. But such a list is now available by
walking over ev_io_map and ev_signal_map! So all they did was
require extra pointer operations to maintain, and extra 8-16 bytes
of storage in each struct event.
To be cowardly and keep the option of going back to having this
redundancy, I'm wrapping the removed code in a set of ifdefs.
This is a first cut; it needs cleanups and stress-testing!! In
particular, it just plain disables a couple of functions that could
probably be saved.
There seems to be a need for an evmap_{io,signal}_foreach() or something.
Previously, event_reinit required a bunch of really dubious hacks,
and violated a lot of abstraction barriers to mess around with lists
of internal events and "pretend" to re-add them.
The new (and fairly well commented!) implementation tries to be much
smarter, by isolating the changes as much as possible to the backend
state, and minimizing the amount of abstraction violations.
Specifically, we now use event_del() to remove events we want to
remove, rather than futzing around with queues in event_reinit().
To avoid bogus calls to evsel->del(), we temporarily replace evsel
with a null-object stub.
Also, we now push the responsibility for calling evsel->add() down
into the evmap code, so that we don't actually need to unlink and
re-link all of our events.
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.
a) this is 2009
b) niels and nick have been comaintainers for a while
c) saying "all rights reserved" when you then go on to explicitly
disclaim some rights is sheer cargo-cultism.
svn:r1065
