This gives you the property that once you have called event_del(E),
you know that E is no longer running or pending or active at all, and
so it is safe to delete the resource used by E's callback.
svn:r1341
Patch from Zack Weinberg. His message:
This one eliminates all use of AC_CHECK_LIB in the configure script.
AC_CHECK_LIB has a serious flaw: if the library you mention *exists*
but is not *necessary* for the function you want, it adds it to
$(LIBS) anyway. This was fine in the days of static libraries,
because the linker would ignore an .a library that didn't contain
anything you needed. However, ELF shared libraries are different
(let's not get into why): the linker will by default record a
DT_NEEDED entry for every shared object mentioned on the link
command line. Thus, every use of AC_CHECK_LIB is a potential
unnecessary DT_NEEDED, making extra work for the dynamic loader. The
cure is simply to use AC_SEARCH_LIBS instead; it first tries to find
the function you ask for in libc, and only if that doesn't work does
it try to use the extra library you mention.
For the same reasons, pkg-config .pc files should distinguish
between the libraries to use for shared linkage (Libs:) and the
additional libraries needed for static linkage (Libs.private:). I
have also made that correction in this patch. I also took the
opportunity to clean up the substitution variables a little and make
absolutely sure that the core library does not get linked against
zlib.
svn:r1338
This fixes part of bug 2800642, I believe, though there is still a
general race condition in multithreaded use of events that we need to
think about.
svn:r1337
New backends like poll and kqueue and so on add fds to the queue in
the order that they are triggered. But the select backend currently
activates low-numbered fds first, whereas the poll and win32 backends
currently favor whatever fds have been on for the longest. This is no
good for fairness.
svn:r1318
Some win32 systems (mostly those using Kaspersky, it would seem)
prevent us from faking socketpair(). This makes our signal
notification code just not work. Our response since 1.4 has been to
assert. For users who would rather work without signals than not work
at all, this has been a regression from 1.3e.
This patch makes adding signal events fail in this case; there's no
reason to kill the whole process.
svn:r1303
Previously, set_flags() would replace all previous user-visible flags.
Now it just sets the flags, and there is a clear_flags() function to
clear other flags.
svn:r1293
OpenSSL uses something like this to implement get/set access for
properties on its BIOs, so that it doesn't need to add a pair of
get/set functions to the vtable struct for every new abstract property
it provides an accessor for.
Doing this lets us make bufferevent_setfd abstract, and implement an
abstract bufferevent_getfd.
svn:r1284
This is a bit of an interface doozy, but it's really needed in order
to be able to document this stuff without apologizing it. This patch
does the following renamings:
evbuffercb -> bufferevent_data_cb
everrorcb -> bufferevent_event_cb
EVBUFFER_(READ,WRITE,...) -> BEV_EVENT_(...)
EVBUFFER_(INPUT,OUTPUT) -> bufferevent_get_(input,output)
All the old names are available in event2/bufferevent_compat.h
svn:r1283
This is stuff that it's easy to get wrong (as I noticed when writing
bench_http), and that takes up a fair amount of space (see http.c).
Also, it's something that we'll eventually want to abstract to use
IOCP, where available.
svn:r1272
Others may remain. I wasn't able to get gcc --std=c89 to build libevent
at all, so I don't know what compiler the original reporter is using here.
Note that this change requires us to disable the part of our rpc code
that uses variadic macros when using a non-gcc compiler. This is a
problem if we want our rpc api to be portable.
svn:r1231
This is patch 2673214 from mmadia. It is correct, since we unconditionally
include signal.h in many other places, and only sometimes include sys/signal.h.
It is necessary to compile on Haiku, I'm told.
svn:r1228
Previously, we could lose the heap property when we removed an item
whose parent was greater than the last element in the heap. We would
replace the removed item with the last element, and consider shifting
it down, but we wouldn't consider shifting it up.
Patch from Marko Kreen.
svn:r1226
This is exceptionally important with multithreaded stuff, where we use
an event to notify the base that other events have been made active.
If the activated events have a prioirty number greater than that of the
notification event, it will starve them, and that's no good.
svn:r1149
In particular, we don't allow adding any data to end front of inbuf
(we do that when we read), or removing it from the front of outbuf (we
drain data only when we write).
svn:r1144
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
