There were a couple of places in the code where we manually kept lock
counts to make sure we never accessed resources without holding a
lock, and that we never released a lock we didn't have. The
lock-debugging code already puts counts on _every_ lock when lock
debugging is enabled, so there is no need to keep these counts around
otherwise. This patch rewrites the ASSERT_FOO_LOCKED macros to all
use a common EVLOCK_ASSERT_LOCKED().
We also teach the lock debugging code to keep track of who exactly
holds each lock, so that EVLOCK_ASSERT_LOCKED() means "locked by this
thread."
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.
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
From the documentation:
Prevent calls that modify an evbuffer from succeeding. A buffer may
frozen at the front, at the back, or at both the front and the back.
If the front of a buffer is frozen, operations that drain data from
the front of the buffer, or that prepend data to the buffer, will
fail until it is unfrozen. If the back a buffer is frozen, operations
that append data from the buffer will fail until it is unfrozen.
We'll use this to ensure correctness on an evbuffer when we're waiting
for an overlapped IO call to finish.
svn:r1143
For overlapped IO (and possibly other stuff) we need to be able to
label an evbuffer_chain as "pinned", meaning that every byte in it
must remain at the same address as it is now until it unpinned. This
differs from being "immutable": it is okay to add data to the end
of a pinned chain, so long as existing data is not moved.
svn:r1142
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
For now, there is just one: enabled. This lets us avoid lots of
mallocs/frees/tailq-manipulations just to turn a callback on and off.
The revised bufferevent code wants this.
svn:r1047
fragmentation in evbuffer_expand by increasing the size of the last buffer
in the chain; as a result with have to keep track of the previous_to_last
chain; provide a evbuffer_validate() function in the regression test to
make sure that all evbuffer are internally consistent.
svn:r699
Make offsetof into evutil_offsetof. Be a little more willing to call evbuffer_chain_align() from evbuffer_expand(). Clarify some docs, and add some XXX comments to note questionable areas.
svn:r677
