Previously, our default lock model kind of assumed that every lock was
potentially a read-write lock. This was a poor choice, since
read-write locks are far more expensive than regular locks, and so the
lock API should only use them when we can actually take advantage of
them. Neither our pthreads or win32 lock implementation provided rw
locks.
Now that we have a way (not currently used!) to indicate that we
really want a read-write lock, we shouldn't actually say "lock this
for reading" or "lock this for writing" unless we mean it.
Previously, there was no good way to request different kinds of lock
(say, read/write vs writeonly or recursive vs nonrecursive), or for a
lock function to signal failure (which would be important for a
trylock mode).
This patch revises the lock API to be a bit more useful. The older
lock calls are still supported for now.
We also add a debugging mode to catch common errors in using the
locking APIs.
It turns out that kqueue_dealloc wasn't calling evsig_dealloc()
(because it doesn't use the main signal handler logic) so the sh_old
array was leaking.
This patch also introduces a fix in evsig_dealloc() where we set
the sh_old array to NULL when we free it, so that main/fork can pass.
From evutil.c:
Some older BSDs (like OpenBSD up to 4.6) used to believe that
giving a numeric port without giving an ai_socktype was verboten.
We test for this so we can apply an appropriate workaround. If it
turns out that the bug is present, then:
- If nodename==NULL and servname is numeric, we build an answer
ourselves using evutil_getaddrinfo_common().
- If nodename!=NULL and servname is numeric, then we set
servname=NULL when calling getaddrinfo, and post-process the
result to set the ports on it.
We test for this bug at runtime, since otherwise we can't have the
same binary run on multiple BSD versions.
svn:r1550
I thought we had a way to do connect() that would never fail
immediately, but always wait for a moment before failing. It
turns out that on FreeBSD it can fail immediately. This is not
FreeBSD's fault, or even a real bug anywhere but in the unit test.
svn:r1549
Basically, we only want to report the 'connected' event because of
the socket connect() finishing when we have an actual socket
bufferevent; on an SSL bufferevent, 'connected' means 'SSL
connection finished.'
This isn't FreeBSD's fault: it just has a connect() that tends to
succeed pretty early.
svn:r1548
This patch from Chris Davis saves some callback depth, and adds proper
ref-counting to bufferevents when there's a deferred evbuffer callback
inflight. It could use a couple more comments to really nail down what
its invariants are.
svn:r1543
The entry points are evutil_getaddrinfo and evdns_getaddrinfo respectively.
There are fairly extensive unit tests.
I believe this code conforms to RFC3493 pretty closely, but there are
probably more issues. It should get tested on more platforms.
This code means we can dump the well-intentioned but weirdly-implemented
bufferevent_evdns and evutil_resolve code.
svn:r1537
Previously, event_base.activequeues was of type "array of pointers to
eventlist." This was pointless: none of the eventlists were allowed
to be NULL. Worse, it was inefficient:
- It made looking up an active event queue take two pointer
deferences instead of one, thus risking extra cache misses.
- It used more RAM than it needed to, because of the extra pointer
and the malloc overhead.
Also, this patch fixes a bug where we were saying
calloc(N,N*sizeof(X)) instead of calloc(N,sizeof(X)) when allocating
activequeues. That part, I'll backport.
Also, we warn and return -1 on failure to allocate activequeues,
rather than calling event_err.
svn:r1525
Previously, if the user scheduled a persistent timeout for {1,0}, we
would schedule the first one at "now+one second", and then when we
were about to run its callback, we would schedule it again for one
second after that. This would introduce creeping delays to the event
that was supposed to run every second.
Now, we schedule the event for one second after it was _last
scheduled_. To do this, we introduce internal code to add an event at
an _absolute_ tv rather than at now+tv.
svn:r1520
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
Yes, some people like to have a BSD-family kernel (thus getting
kqueue) with a GNU-family libc (thus occasionally mandating
_GNU_SOURCE).
Thanks to Debian for noticing this.
svn:r1514
This bug was introduced by the code to make the backend able to safely release the base lock while calling select().
Also, we change win32select.c to the same 32-fds-to-start default as the rest of the backends, so that the main/many_events test can test it. It was at 64-to-start, so the test wasn't hitting it.
svn:r1513
