Hi
FWIW in my experience your second idea would be a common solution
(queuing a new event to move the free on to the dispatch thread where it
can be guaranteed the event's callbacks are all done).
On Fri, Feb 24, 2012 at 09:34:12PM -0500, Nick Mathewson wrote:
> On Fri, Feb 24, 2012 at 8:14 PM,
On Fri, Feb 24, 2012 at 8:14 PM, Amarin Phaosawasdi
wrote:
> Hello,
>
> About a year ago, there was a thread about deadlocking in
> bufferevent_openssl in multi-threaded mode
> (http://archives.seul.org/libevent/users/Jan-2011/msg00019.html).
>
> We've run into the same problem.
>
> Our minimal fi
On Fri, Feb 24, 2012 at 07:39:26PM -0600, Mark Ellzey wrote:
> On Fri, Feb 24, 2012 at 07:14:58PM -0600, Amarin Phaosawasdi wrote:
> > Hello,
> >
> > About a year ago, there was a thread about deadlocking in
> > bufferevent_openssl in multi-threaded mode (
> > http://archives.seul.org/libevent/use
On Fri, Feb 24, 2012 at 07:14:58PM -0600, Amarin Phaosawasdi wrote:
> Hello,
>
> About a year ago, there was a thread about deadlocking in
> bufferevent_openssl in multi-threaded mode (
> http://archives.seul.org/libevent/users/Jan-2011/msg00019.html).
>
> We've run into the same problem.
>
Her
Hello,
About a year ago, there was a thread about deadlocking in
bufferevent_openssl in multi-threaded mode (
http://archives.seul.org/libevent/users/Jan-2011/msg00019.html).
We've run into the same problem.
Our minimal fix (as opposed to the patch mentioned, which adds atomic
operations to evth
