The EVLOCK_LOCK and EVLOCK_UNLOCK macros already check to make sure
that the lock is present before messing with it, so there's no point
in checking the lock before calling them.
A good compiler should be able to simplify code like
if (lock) {
if (lock)
acquire(lock);
}
, but why count on it?
Debug mode needs to be enabled before any event is setup or any
event_base is created. Otherwise, we will not have recorded when events
were first setup or added, and so it will look like a bug later when we
delete or free them.
I have already confused myself because of this requirement, so let's
make Libevent catch it for the next poor forgetful developer like me.
Of the backends that support edge-triggered IO, most (all?) do not
support attempts to mix edge-triggered and level-triggered IO on the
same FD. With debugging mode enabled, we now detect and refuse attempts
to add a level-triggered IO event to an fd that already has an
edge-triggered IO event, and vice versa.
The old code would use type_var_add() for its side-effect of expanding the
array, then leak the new object that was added to the array.
The new code adds a static function to handle the array resizing.
Of course, FreeBSD has its own arc4random() implementation, so this should
never actually be needed. Still, it's good to paint the underside of the
wagon.
William Ahern points out that if the user has chrooted, they might not
have a working /dev/urandom. Linux and many of the BSDs, however,
define a sysctl interface to their kernel random number generators.
This patch takes a belt-and-suspenders approach and tries to do use the
sysctl _and_ the /dev/urandom approach if both are present. When using
the sysctl approach, it tries to bulletproof itself by checking to make
sure that the buffers are actually set by the sysctl calls.
The old logging code was littered with places where we stored messages in
static char[] fields. This is fine in a single-threaded program, but if you
ever tried to log evdns messages from two threads at once, you'd hit a race.
This patch also refactors evdns's debug_ntop function into a more useful
evutil_sockaddr_port_format() function, with unit tests.
When searching is enabled, evdns may make multiple requests before
calling the user callback with the result. This is a problem because
the same evdns_request handle is not retained for each search request,
so the user cannot reliably cancel the request.
This patch attempts to ensure that evdns_request persists accross
search requests.
Previously, when a signation() or signal() call failed, we would free
the element we added to sh_old, but not actually clear the pointer.
This would leave a dangling pointer in sh_old that could cause a
crash later.
The EVUTIL_CLOSESOCKET() macro required you to include unistd.h in your
source for POSIX. We might as well turn it into a function: an extra
function call is going to be cheap in comparison with the system call.
We retain the EVUTIL_CLOSESOCKET() macro as an alias for the new
evutil_closesocket() function.
(commit message from email by Nick and Sebastian)
This makes evprc setup more extensible, and helps with Shuo Chen's
work on implementing Google protocol buffers rpc on top of Libevent 2
evrpc.
This patch breaks binary compatibility with previous versions of
Libevent, since it changes struct evrpc and the signature of
evrpc_register_generic(). Since all compliant code should be calling
evrpc_register_generic via EVRPC_REGISTER, it shouldn't break source
compatibility.
(Code by Shuo Chen; commit message by Nick)
The evbuffer_remove() function copies data from the front of an
evbuffer into an array of char, and removes the data from the buffer.
This function behaves the same, but does not remove the data. This
behavior can be handy for lots of protocols, where you want the
evbuffer to accumulate data until a complete record has arrived.
Lots of people have asked for a function more or less like this, and
though it isn't too hard to code one from evbuffer_peek(), it is
apparently annoying to do it in every app you write. The
evbuffer_peek() function is significantly faster, but it requires that
the user be able to handle data in separate extents.
This patch also reimplements evbufer_remove() as evbuffer_copyout()
followed by evbuffer_drain(). I am reasonably confident that this
won't be a performance hit: the memcpy() overhead should dominate the
cost of walking the list an extra time.
The previous evbuffer_expand was not only incorrect; it was
inefficient too. On all questions of time vs memory tradeoffs, it
chose to burn time in order to avoid wasting memory. The new code
tries to be a little more balanced: it only resizes an existing chain
when doing so doesn't require too much copying, and when failing to do
so would waste a lot of the chain's space.
This patch also rewrites evbuffer_chain_insert to work properly with
last_with_datap, and adds a few convenience functions to buffer.c.
