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.
The evhttp_parse_query API is a bit misdesigned; all the other
evkeyvalq stuff is abstract and lets you get away with having a header
stub, but evhttp_parse_query seems to require that you instantiate an
empty evkeyvalq of your own.
Though the C standards allow it, it's apparently possible to get MSVC
upset by saying "struct { int field; } (declarator);" instead of
"struct {int field; } declarator;", so let's just not do that.
Bugfix for 3044492
(commit msg by nickm)
These structures used TAILQ for the lists of events waiting on a
single fd or signal. But order doesn't matter for these lists; only
the order of the active events lists actually matters.
Generally, LIST_ can be a little faster than TAILQ_ for most
operations. We only need to use TAILQ_ when we care about traversing
lists from tail-to-head, or we need to be able to add items to the end
of the list.
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.
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.
Libevent's current timeout code is relatively optimized for the
randomly scattered timeout case, where events are added with their
timeouts in no particular order. We add and remove timeouts with
O(lg n) behavior.
Frequently, however, an application will want to have many timeouts
of the same value. For example, we might have 1000 bufferevents,
each with a 2 second timeout on reading or writing. If we knew this
were always the case, we could just put timeouts in a queue and get
O(1) add and remove behavior. Of course, a queue would give O(n)
performance for a scattered timeout pattern, so we don't want to
just switch the implementation.
This patch gives the user the ability to explicitly tag certain
timeout values as being "very common". These timeout values have a
cookie encoded in the high bits of their tv_usec field to indicate
which queue they belong on. The queues themselves are each
triggered by an entry in the minheap.
See the regress_main.c code for an example use.
svn:r1517
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
Stop pretending that u_char and u_short are standard types that win32 is dumb not to have. In fact, u_char can really just be spelled out, and u_short was usually just a bad way of saying ev_uint16_t.
svn:r808
