We need to comb the rest of the code to make sure that we don't blindly wrap
functions in LOCK(x), UNLOCK(x) when those functions might contain a FREE(x)
in the middle.
Rocco Carbone found and reported this bug.
svn:r1384
This code adds a new Bufferevent type that is only compiled when the
openssl library is present. It supports using an SSL object and an
event alert mechanism, which can either be an fd or an underlying
bufferevent.
There is still more work to do: the unit tests are incomplete, and we
need to support flush and shutdown much better. Sometimes events are
generated needlessly: this will hose performance.
There's a new encrypting proxy in sample/le-proxy.c.
This code has only been tested on OSX, and nowhere else.
svn:r1382
The problem was introduced when we changed the semantics of
get_supported_methods() to reflect all the methods that exist.
Previously, it had not returned methods disabled from the environment,
but the test didn't know that.
svn:r1379
They're now called evtag_encode_int(64). The old names are available
as macros in event2/tag_compat.h.
Also, add unit tests for encode/decode_int64.
svn:r1365
These are done as variations of test_bufferevent_connect, since that
one exercises event callbacks as well as read/write callbacks.
The coverage for bufferevent.c is now up to about 87%, from about 70%.
svn:r1358
Rationale: we hold a lock on the bufferevent when its callbacks are
executing, so we need to release the lock afterwards. But the
callback might free the bufferevent, so unless we're holding a
reference on the bufferevent, the lock might not be there for us to
release.
svn:r1347
Previously, events that were disabled using EVENT_NO* were left out of
event_get_supported_methods(). This was wrong, broke unit tests
(under some circumstances) and left the user with no good way to tell
which methods were actually compiled in.
Fixes bug 2821015.
svn:r1344
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 description:
This one might be a little more controversial. Libtool's -release and
-version-info options are supposed to be mutually exclusive, but it doesn't
either enforce that or make it sufficiently clear in the manual. Using
both makes the -version-info switch ineffective; you will get sonames like
"libevent-2.0.so.1", "libevent-2.1.so.1", etc., even though version 2.1
will presumably be backward ABI compatible with 2.0.
This patch just takes out the -release switches and bumps the -version-info
value to 2:0:0 so that people looking at the files in /usr/lib will not be
confused (it'll be "libevent.so.2"). This does change the soname, but the
current release is labeled an alpha, and it would be better to stop using
both switches as soon as possible, before someone over at libtool
headquarters decides to enforce the mutual exclusivity here...
Note that libevent_pthreads is not being linked with any versioning
switches I didn't change that because I wasn't sure whether it was
intentional.
svn:r1339
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
