gmane.comp.lib.libevent.user

Re: questions about bufferevent callbacks in multithreaded code

Sashan Govender — 2013-05-16T14:09:30


Thanks. I'll give 2.1.3-alpha a go. I'll also try and strip away more of my
code till I have a reproducible case for libevent or I find the problem in
my code. I've tried enabling the multithreaded debugging
(evthread_enable_lock_debugging) but that doesn't trigger any assertions.

Re: questions about bufferevent callbacks in multithreaded code

Nick Mathewson — 2013-05-15T14:37:47

Right.


Right, so long as there isn't some kind of a deadlock scenario where
the two threads are acquiring locks in different order.

If you *are* hitting a mysterious bufferevent-related deadlock, though
,you might want to check out Libevent 2.1.3-alpha: it has a fix for a
longstanding tricky deadlock in bufferevents related to how
event_del() handles an event that is currently running its callback.

Re: questions about bufferevent callbacks in multithreaded code

Sashan Govender — 2013-05-15T10:24:59

So in theory the following scenarios should not deadlock:

This all happens in a single thread:
1) a bufferevent read callback is triggered (lock acquired)
2) the user supplied callback function reads the data and calls
bufferevent_write (lock acquired - ok because using a recursive mutex)

and neither should this where 2 threads are involved:
1) a bufferevent read callback is triggered
2) the user supplied callback function does some stuff (callback ends ->
lock released by libevent)
3) bufferevent_write is called from another thread


On Thu, May 2, 2013 at 2:12 AM, Nick Mathewson <nickm< at >freehaven.net> wrote:

Re: Is evthread_use_pthreads required for isolated evdns event_bases?

Nick Mathewson — 2013-05-09T15:19:47

 [...]

I'm indifferent, so long as user code that works today continues to work.

Re: Is evthread_use_pthreads required for isolated evdns event_bases?

Joseph Spadavecchia — 2013-05-09T09:49:36


Anytime.  This looks like a fun task.  I should be able to start work on it next week.

[…]

Sounds good.  Shall I make the PRNG not shared by default, or do you want it the other way around?

Many thanks.
*Joe

***********************************************************************
To unsubscribe, send an e-mail to majordomo< at >freehaven.net with
unsubscribe libevent-users    in the body.

libevent kqueue not working properly on fd returned from zmq_getsockopt()

Pritesh Acharya — 2013-05-08T17:27:11

This problem is also related to zmq. I'm writing a service in C programming
using libevent and zmq. Msg is pushed from python code to C service using
PUSH-PULL pattern.

fd received from zmq socket:

void *receiver = zmq_socket (base.zmq_ctx, ZMQ_PULL);
zmq_connect (receiver, "tcp://localhost:5557");int fd=0;size_t fd_len
= sizeof(fd);
zmq_getsockopt (receiver, ZMQ_FD, &fd, &fd_len);

Using Libevent, event registered with fd for persistent read

struct event *read_data_on_zmq =event_new(base.evbase, fd, EV_READ |
EV_PERSIST , read_data_on_zmq_cb,receiver);
event_add(read_data_on_zmq,NULL);
event_base_dispatch(base.evbase);

On the callback method I'm doing a non-blocking receive

void read_data_on_zmq_cb(evutil_socket_t fd, short what, void *arg){
    char *msg = calloc(1024,sizeof(char));
    int size = zmq_recv (receiver, msg, 255, ZMQ_DONTWAIT);
    if (size != -1)
    {
        puts ("is size is not -1");
        printf("msg = %s\n",msg);
    }

    zmq_getsockopt (receiver, ZMQ_EVENTS, &fd, &fd_size);

}

In the python code I'm continuously sending message to the socket.

import zmqimport time

c=zmq.Context()
s=c.socket(zmq.PUSH)
s.bind('tcp://127.0.0.1:5557')while(True):
    s.send("abc")
    time.sleep(2)

The problem is I'm only able to receive the message few time, after that
the event callback never gets hit. And the msg from python gets lost. What
is the problem here?

Re: Is evthread_use_pthreads required for isolated evdns event_bases?

Nick Mathewson — 2013-05-05T23:03:57

 [...]

A patch would definitely be a good help.  Thank you!  The most
important thing to me here would be that the abstraction needs to be
good; the evdns_base should be holding some kind of "struct
evutil_secure_random_state", so that it's easier to swap in a better
backend than arc4random later.

Github pull requests probably work best these days for me.

best wishes,

Re: Is evthread_use_pthreads required for isolated evdns event_bases?

Joseph Spadavecchia — 2013-05-03T17:12:50

Hi Nick.

On Fri, 3 May 2013 11:47:13 -0400, Nick Mathewson <nickm< at >freehaven.net>
wrote:
[...]

Oh, I didn't know there was a shared PRNG in evdns.  I thought evdns_base
behaves like event_base, i.e., that they shared nothing by default.

[...]

Thanks.  That would work for me.

[...]

My only thought is perhaps the PRNG should be per evdns_base by default.

Oh, and if you could use some help, then I'd be happy to submit a patch.

Many thanks.
*Joe

***********************************************************************
To unsubscribe, send an e-mail to majordomo< at >freehaven.net with
unsubscribe libevent-users    in the body.

Re: Is evthread_use_pthreads required for isolated evdns event_bases?

Nick Mathewson — 2013-05-03T15:47:13

 [...]

Under the current architecture, you do indeed need to initialize
threading for any resource to be shared across threads, which *does*
include the PRNG.  Unfortunately, evdns does not currently have an
option like EVENT_BASE_FLAG_NOLOCK, so once threading is initialized,
every evdns_base is going to have a lock that it doesn't need.

I'd be open to work to change this, including by:
  * Letting the PRNG be thread-specific.
  * Adding an option to make the PRNG be evdns_base-specific
  * Adding a flag like EVENT_BASE_FLAG_NOLOCK for evdns_base initialization.

Other thoughts?

yrs,

Is evthread_use_pthreads required for isolated evdns event_bases?

Joseph Spadavecchia — 2013-05-03T13:41:56

Hi there,

I'm developing a multithreaded proxy server (running on Linux 2.6.32;
libevent-2.0.20-stable), where each event_base is isolated to a single
thread.

As I understand, by isolating the event_bases per thread and not calling
evthread_use_pthreads(), I can avoid locking overheads.  AFAIK,
evthread_use_pthreads() only needs to be called when multiple threads share
an event_base.  If this is incorrect, then please disregard this email.
Otherwise, read on... :)

On one particular site, after about two weaks of heavy load (e.g. 500
req/sec), the evdns.c:transaction_id_pick() gets stuck in an infinite loop
(all threads using evdns get stuck and requests cannot be served).

Via a gdb debug session, I found that transaction_id_pick()'s call to
evutil_secure_rng_get_bytes() always returns the same trans_id.  I could
not get any further due to compiler optimizations, so I rebuilt libevent
without optimizations and allowed it to run for another two weeks on the
customers site.  Again, evdns.c:transaction_id_pick() got stuck in an
infinite loop.

This time I found that evdns's RC4-ish pseudorandom number generator
arc4random.c:arc4_getbyte() is always returning the same value.  Inspecting
further, I found that the prng's permutation table (rs) is in an impossible
state (according to the arc4 logic):

(gdb) p rs
$1 = {i = 212 '\324', j = 102 'f',
  s =
"\357\357\357\357\357\357\357\357\357\357\357\357\357\357\357\357\357\357\357\357\357\357\357\357\357\357\357\357\357\357\357\357\357\357\357\357\357\357\357\357\357\357\357\357\357\357\357\357\357\357\357\357\357\357\357\357\357\357\357\357\357\357\357\357\357\357\357\357\357\357\357\357\357\357\357\357\357\357\357\357\357\357\357\357\357\357\357\357\357\357\357\357\357\357\357\357\357\357\357\357\357\357\357\357\357\357\357\357\357\357\357\357\357\357\357\357\357\357\357\357\357\357\357\357\357\357\357\357\357\357\357\357\357\357\357\357\357\357\357\357\357\357\357\357\357\357\357\357\357\357\357\357\357\357\357\357\357\357\357\357\357\357\357\357\357\357\357\357\357\357\357\357\357\357\357\357\357\357\357\357\357\357\357\357\357\357\357\357\357\357\357\357\357\357\357\357\357\357\357\357\357\357\357\357\357\357\357\357\357\357\357\357\357\357\357\357\357\357\357\357\357\357\357\357\357\357\357\357\357\357\357\357\357\357\357\357\357\357\357\357\357\357\357\357\357\357\357\
 357\357\
357\357\357\357\357\357",
<incomplete sequence \357>}
(gdb) p arc4_count
$2 = 1053737

So, something has trampled the memory.

Looking back through the libevent code, it seems that the prng's locks are
only initialised if evthread_use_pthreads() or
evthread_enable_lock_debuging() is called.

evthread_use_pthreads()
evthread_set_lock_callbacks()
event_global_setup_locks_()
evutil_secure_rng_global_setup_locks_()
arc4rand_lock()

Meanwhile, the arc4 permutation table appears to be shared by all
event_bases.

struct arc4_stream {
        unsigned char i;
        unsigned char j;
        unsigned char s[256];
};

....

static struct arc4_stream rs;

Is this a bug or is evthread_use_pthreads() required for multiple --
isolated -- threads to use evdns?

Cheers.
*Joe

***********************************************************************
To unsubscribe, send an e-mail to majordomo< at >freehaven.net with
unsubscribe libevent-users    in the body.

[possibly OT] Updated giant inventory of headers available on various OSes

Zack Weinberg — 2013-05-02T03:34:07

A while ago I posted a call for help (only to autoconf< at >) taking inventories
of which C headers are provided by which OSes.  It rapidly became clear
that my methodology was far too crude, and I've spent much of the past six
weeks coding up something much more sophisticated.  The project is now at
the point where I feel comfortable sharing it with a wider audience.
Please see http://hacks.owlfolio.org/header-survey/ for the results so far,
and https://github.com/zackw/header-survey/ for code, raw data, and
instructions for contributing inventories for OSes not yet in the big
table.  (Big table only known to work properly in Firefox, say sorry -
patches for the bad stylin' in Webkit most welcome.  I've exhausted my
ability to sling CSS.)

If you sent me an inventory already but your OS is not in the big table, I
need you to send it again using the current `scansys.py`.  To those of you
who told me that it didn't work with your version of Python, take heart -
it is now tested to work with 2.0.  Yes, 2.0.

zw

ANN: Libevent 2.1.3-alpha is released!

Nick Mathewson — 2013-05-02T03:10:53

Announcing Libevent 2.1.3-alpha
===============================

Libevent 2.1.3-alpha is released!

This is the third release in the Libevent 2.1 series. As the "alpha"
should tell you, this is not a stable release: you should not run it
unless you're willing to debug together.  If you want a stable version
of Libevent, stick to the 2.0 series for now.

The package is available from the website, at http://libevent.org/

There are GPG signatures there too; you should probably verify them,
to make sure you get the software you think you are getting.

What's new in Libevent 2.1.3-alpha
==================================

This release has a bunch of stuff, including:

   * An experimental "finalization" feature to try to solve the
     deadlock in multithreaded bufferevent use.
   * Numerous bug and portability fixes.

For explanations of what's changed in 2.1 so far, see "What's New In
Libevent 2.1", available as "whatsnew-2.1.txt" in the source distribution,
or online at https://raw.github.com/libevent/libevent/master/whatsnew-2.1.txt

The whole darn ChangeLog
========================

 Libevent 2.1.3-alpha fixes various bugs, adds new unit tests, and cleans
 up the code in a couple of places. It has a new callback in evhttp for
 reporting errors during a request, a new feature for allowing evdns to
 not keep the event_base looping when there are no requests inflight, and
 example code for writing an https client.

 Libevent 2.1.3-alpha also has an important new (experimental) event
 finalization feature to allow safe event teardown in multithreaded
 programs. This ought to fix the longstanding bug with deadlocks in
 multithreaded use of SSL-based bufferevents that some people have been
 experiencing since Libevent 2.0.


 Core (event finalization)
   o Implement event_finalize() and related functions to avoid certain
     deadlocks (8eedeab)
   o Use finalization feature so bufferevents can avoid deadlocks (02fbf68)
   o Always run pending finalizers when event_base_free() is called (e9ebef8)
   o Remove bufferevent_del_generic_timeout_cbs as now unused (4ea4c6a)
   o More documentation for finalization feature (a800b91)
   o Make the event_finalize* functions return an error code (5d11f4f)
   o Mark the finalize stuff as experiemental in case it needs to
     change (23e2e29)

 Evdns
   o evdns: New flag to make evdns not prevent the event loop from
     exiting (6b7fa62 Azat Khuzhin)

 Bugfixes (Core)
   o Make event_remove_timer behave correctly with persistent timers (5623e80)
   o Unit test for event_remove_timer with EV_PERSIST. (96150dd)
   o Double-check next timeout when adding events (9443868 Nate Rosenblum)
   o event_base_update_cache_time should be a no-op if the loop isn't
     running (5e6fa2a)

 Bugfixes (evhttp, crash fix, from 2.0)
   o fix #73 and fix http_connection_fail_test to catch it (b618204 Greg Hazel)

 Bugfixes (compilation and portability, from 2.0)
   o Fix compilation with WIN32_HAVE_CONDITION_VARIABLES enabled (7e45739)
   o Fix missing AC_PROG_SED on older Autoconfs (9ab2b3f Tay Ray Chuan)
   o Backport libevent to vanilla Autoconf 2.59 (as used in RHEL5)
     (74d4c44 Kevin Bowling)
   o Use AC_CONFIG_HEADERS in place of AM_CONFIG_HEADERS for autmake
     1.13 compat (817ea36)
   o Rename configure.in to configure.ac to appease newer autoconfs (0c79787)
   o Avoid using top_srcdir in TESTS: new automakes do not like this (a55514e)

 Bugfixes (resource leaks/lock errors on error, from 2.0)
   o Avoid leaking fds on evconnlistener with no callback set (69db261)
   o Avoid double-close on getsockname error in evutil_ersatz_socketpair
     (0a822a6)
   o Fix a locking error in bufferevent_socket_get_dns_error. (0a5eb2e)

 Documentation Fixes (from 2.0)
   o Fix a mistake in evbuffer_remove() arguments in example http server code
     (c322c20 Gyepi Sam)
   o Fix a typo in a comment in buffer.h. Spotted by Alt_F4 (773b0a5)

 Documentation Fixes
   o minor documentation typos (809586a Patrick Pelletier)
   o Fix cut-and-paste err in whatsnew-2.1 (49905ac)
   o Fix comment to refer to sample/include.am correctly (9e8cdf3 Sebastian
     Hahn)
   o Fix typo : Dispatching instead of Dispaching (0c2bacc Volker Lendecke)
   o fix some hinky indentation in evhttp_make_request (80e220e Patrick
     Pelletier)
   o "buffer" spelling (a452811 Patrick Pelletier)
   o Specify return behavior in header for evbuffer_pullup() in corner case
     (cf8d1cd Dan Petro)
   o Clarify an important point about event_base_foreach_event() (920a5e6)

 Compilation Fixes/Tool Support
   o avoid valgrind false positive by zeroing epoll_event (1258614 Patrick
     Pelletier)
   o Fix harmless clang enum warning (b452a43 Sebastian Hahn)
   o remove all exes on "make clean", not just regress.exe (974bfa0 Patrick
     Pelletier)
   o Make --disable-libevent-regress work again (787fd74)
   o Do not build strlcpy.c when it will have no code. (4914620)

 Portability Fixes
   o When EWOULDBLOCK is not EAGAIN, treat it as equivalent to it (bf7a0ff)
   o Preliminary changes for Minix3. (0dda56a Nicholas Heath)
   o Use AC_CONFIG_HEADERS in place of AM_CONFIG_HEADERS for autmake 1.13
     compat (bf278b)
   o Avoid using $(top_srcdir) in TESTS. (2863c83)
   o build test/test-script.sh on systems with a less-featureful $< (f935e21)
   o Implement EVUTIL_ERR_IS_EAGAIN on windows. (42aaf4d)

 Evhttp changes:
   o Fix ipv6 support for http. When URL contain domain, not IP
     address. (71e709c Azat Khuzhin)
   o uri decode: fix for warning "use of uninitialised value" (64b6ece Azat
     Khuzhin)
   o uri decode: changed the test for the existence of the next character
     (e1903e3 Azat Khuzhin)
   o Move prototype of evhttp_decode_uri_internal() to http-internal.h
     (de8101a Azat Khuzhin)
   o Test: decoding just part of string with evhttp_decode_uri_internal()
     (1367653 Azat Khuzhin)
   o Add new error_cb for actual reporting of HTTP request errors. (7b07719
     Azat Khuzhin)
   o Add test for EVREQ_HTTP_REQUEST_CANCEL into http_cancel_test() (862c217
     Azat Khuzhin)
   o Drop extra header http_struct.h from regress_http.c (54cc800 Azat Khuzhin)

 Testing
   o Add regress test ipv6_for_domain. (9ec88bd Azat Khuzhin)
   o Add an environment variable (EVENT_DEBUG_MODE) to run unit tests in debug
     mode (2fad0f3)
   o Add a test with an active_later event at event_base_free time. (1c3147f)
   o Make all tests pass under EVENT_DEBUG_MODE=1 (b1b054f)
   o Add some verbose notes to bufferevent unit tests (9d893c9)
   o New test for active_later->active transition on event_active (a153874)
   o New tests for event_base_foreach_event() (0b096ef)
   o Unit tests for event_base_gettimeofday_cached() and
     event_base_update_cache_time() (30ea291)
   o A test for event_get_assignment() (f09629e)
   o More unit tests for initializing common timeouts. (d596739)
   o Fix a bug in the new main/event_foreach test (702c9aa)

 Windows:
   o use FormatMessage for winsock errors (0c6ec5d, 2078e9b, 4ccdd53, c9ad3af
     Patrick Pelletier)
   o a program to print out the error strings for winsock errors (7296512
     Patrick Pelletier)
   o Fix a warning introduced in 0c6ec5d8 (eeb700c)
   o Fix another warning introduced in 0c6ec5d8 (ed26561)

 Examples (http)
   o Add sample/https-client.c, an example of stacking evhttp as a client on
     top of bufferevent_ssl. (be46c99 Catalin Patulea)
   o use ${OPENSSL_LIBS} instead of -lssl -lcrypto (bf31fa5 Patrick Pelletier)
   o https-client was putting newlines at 256-byte boundaries (42d7441 Patrick
     Pelletier)
   o better handling of OpenSSL errors (5754d96 Patrick Pelletier)
   o use Debian's default root certificate location (aacd674 Patrick Pelletier)
   o use iSECPartners code to validate hostname in certificate (64d9f16
     Patrick Pelletier)
   o avoid sign mismatch warning in openssl_hostname_validation.c (6021cb5
     Patrick Pelletier)
   o pull in wildcard matching code from cURL (4db9da6 Patrick Pelletier)
   o Another tweak to https-client.c (95acdaa)
   o Remove http_struct.h usage in sample/https-client.c (8a90a85)


Plans for Libevent 2.1
======================

There are a bunch more features I'd like to get into Libevent 2.1, but I
understand that people would like a stable release soon, and so would I. So
I'm going to give myself the month of May to see if I can get any more done,
and then start putting out release candidates.

Some features I'd _like_ to get done in 2.1 are:
  * UDP bufferevents.
  * An improved win32 backend, based on chrisd's hybrid-select work.
  * Drop-in support for better resolvers.
  * An NSPR-backed bufferevent implementation for people who prefer
    their TLS to be NSS-flavored.
  * A unified callback system so that bufferevent callbacks, event callbacks,
    evdns callbacks, evbuffer callbacks (and so on) can all use the same
    callback logic.
But of course, there's no way I can get this all done myself in a month.

Since Libevent 2.1 is in alpha, I'm going to continue taking bugfix
patches for 2.0, but I'm going to be even more strict about what counts
as a bugfix. I'm going to let 2.1.3-alpha sit out there for a while before
releasing the next 2.0, to try to make sure that none of bugfixes currently
pending for 2.0 are really regressions.

I expect Libevent 2.1 to be much less disruptive than Libevent 2.0 for
people who want to upgrade.  Nevertheless, I'm going to continue
supporting 2.0 for a good while after 2.1 becomes stable.

Acknowledgments
===============

Thanks to everybody who helped with code, bug reports, and suggestions,
including but not limited to:

Kevin Bowling
Hing Cheung
Tay Ray Chuan
Sebastian Hahn
Greg Hazel
Nicholas Heath
Xiuqiang Jiang
Azat Khuzhin
Volker Lendecke
Catalin Patulea
Patrick Pelletier
Dan Petro
Nate Rosenblum
Gyepi Sam
***********************************************************************
To unsubscribe, send an e-mail to majordomo< at >freehaven.net with
unsubscribe libevent-users    in the body.

Re: questions about bufferevent callbacks in multithreaded code

Nick Mathewson — 2013-05-02T01:12:25

Ordinarily, yes. You can override this with the
BEV_OPT_UNLOCK_CALLBACKS option, as described in
http://www.wangafu.net/~nickm/libevent-book/Ref6_bufferevent.html


Yes.

Yrs,

questions about bufferevent callbacks in multithreaded code

Sashan Govender — 2013-05-01T16:07:29

Hi

I need to clarify my understanding of how bufferevent objects work with
mulithreaded code. If a bufferevent triggers a callback (read or write)
does it hold a lock until that callback completes? Do the locks use a
recursive mutex?

Thanks

Re: Bufferevent filter with greedy sender

Nick Mathewson — 2013-04-28T01:45:05

I think you want to look into watermarks: it's a way to tell Libevent
"Don't let this buffer get more full than X" or "don't bother me
unless this buffer has at least X bytes".

I'm too distracted to post good code for using watermarks together
with filters tonight, but the idea should be pretty straightforward
from the documentation and the reference manual.  (If somebody _can_
write a good example, possibly nice and terse for inclusion in the
manual, that would rock.)  Let us know if it still doesn't make sense
or doesn't work for you though.

peace,

Re: Bufferevent filter with greedy sender

kgardenia42 — 2013-04-27T18:45:02

I should add: the low level read callback does eventually get called
but only after hundreds of calls to the filter's input callback.  What
I'm asking for is a way to call the read callback sooner so the dst
buffer doesn't get bloated.  How can I control this behavior?

On Sat, Apr 27, 2013 at 6:52 PM, kgardenia42 <kgardenia42< at >googlemail.com> wrote:
***********************************************************************
To unsubscribe, send an e-mail to majordomo< at >freehaven.net with
unsubscribe libevent-users    in the body.

Bufferevent filter with greedy sender

kgardenia42 — 2013-04-27T17:52:24

Hi,

I have a bufferevent_filter to parse some protocol data from the "src"
evbuffer and unwrap it into the "dst" evbuffer.

This all works fine.  The problem I have, however, is that when there
is a greedy sender sending a lot of data the input_filter just keeps
getting called hundreds or thousands of times, massively bloating the
dst buffer.

What I would *like* to happen is for the lower level read callback (on
the bev which is wrapped by the filter) to be called so that dst gets
drained and I don't get the bloat.

I've read the docs and I can't seem to grock this part of it and
couldn't find a relevant example.  Can someone please advise how to
accomplish this?

I see that the filter callback has a "enum bufferevent_flush_mode
state" parameter.  Is this relevant here?

Thanks,
***********************************************************************
To unsubscribe, send an e-mail to majordomo< at >freehaven.net with
unsubscribe libevent-users    in the body.

Re: Simple question about multithreading SSL bufferevents.

Nick Mathewson — 2013-04-25T21:26:54

Cool!  In that case, the best way to test would be to either take the
current git master, then merge in the branch "21_deadlock_fix" from
https://github.com/nmathewson/libevent/ .

Alternatively, you could wait for 2.1.3-alpha, which I hope will be
out pretty soon.

best wishes,

Re: Simple question about multithreading SSL bufferevents.

John — 2013-04-25T21:23:38

Nick,

I have made my code capable of running multiple sets of single-threaded SSL bufferevent+event_base (i.e. works with current libevent 2.0) as well as able to run fully multithreaded (breaks with current libevent 2.0) I will be happy to test the changes in my real softwarewhich would probably be a better stress test than the simple test software I posted before.

Thanks,
-John


________________________________
From: Nick Mathewson <nickm< at >freehaven.net>
To: libevent-users< at >freehaven.net; John <jjchnk-libevent< at >yahoo.com> 
Sent: Thursday, April 25, 2013 11:36 AM
Subject: Re: [Libevent-users] Simple question about multithreading SSL bufferevents.


On Tue, Mar 26, 2013 at 6:32 PM, John <jjchnk-libevent< at >yahoo.com> wrote:

FWIW, I can confirm that my current "21_deadlock_fix" branch makes
your example code run as expected.  See the thread "RFC: strategy for
deadlock avoidance and safe finalization in Libevent 2.1" from earlier
this month for more information on that.  I hope to clean it up in the
next few days and merge it soon. Ideally, I would like to get the next
Libevent 2.1.x-alpha released over this weekend.

best wishes,

Re: Simple question about multithreading SSL bufferevents.

Nick Mathewson — 2013-04-25T18:36:02

FWIW, I can confirm that my current "21_deadlock_fix" branch makes
your example code run as expected.  See the thread "RFC: strategy for
deadlock avoidance and safe finalization in Libevent 2.1" from earlier
this month for more information on that.  I hope to clean it up in the
next few days and merge it soon. Ideally, I would like to get the next
Libevent 2.1.x-alpha released over this weekend.

best wishes,

Re: Could not use event_base_foreach_event

Nick Mathewson — 2013-04-25T13:54:33

On Thu, Apr 25, 2013 at 1:24 AM, Pritesh Acharya
<priteshacharya< at >gmail.com> wrote:

No, but it's only in Libevent 2.1, not in Libevent 2.0.  It sounds
like maybe you're building with headers from Libevent 2.1, but linking
against libevent 2.0.