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