On 2013-02-18 5:12 PM, Zack Weinberg wrote:
To fix things, we need to change abstract behavior in two places. First,
when you event_del() an event while the event loop to which it belongs
is running, it does not actually get disassociated from the event loop
until the next time the loop is about
On 2012-08-08 2:52 PM, Nick Mathewson wrote:
On Mon, Aug 6, 2012 at 2:42 PM, Matthieu Nottale wrote:
I'm experiencing a deadlock on 2.0.19 while calling bufferevent_free frome
thread A, while thread B is in event_base_dispatch.
Ouch. This is a known bug. This fix is going to be hard. I wro
Hi Nick/Others,
The thing to realise is that the current libevent _API_ doesn't lead
itself to being thread-safe.
This is my motivation behind my original comment of "threading should
be left to the API user, not the library."
I had the same problem in Squid. The internal APIs don't lead
themsel
On Wed, Aug 8, 2012 at 11:43 PM, Dave Hart wrote:
> One solution that comes to mind is to add a (for example)
> event_del_nowait(), or event_del_nonblocking() which requires the
> event in question be allocated dynamically via libevent, and therefore
> can safely use the dead list approach of queu
One solution that comes to mind is to add a (for example)
event_del_nowait(), or event_del_nonblocking() which requires the
event in question be allocated dynamically via libevent, and therefore
can safely use the dead list approach of queuing the deallocation to
be done by the thread running the e
On Wed, Aug 8, 2012 at 6:44 PM, Adrian Chadd wrote:
> On 8 August 2012 15:30, Nick Mathewson wrote:
>
>> Specifically, let me follow up with what I need: I need people with
>> good programming taste to read and understand that message, and let me
>> know whether you've got any good ideas for fixi
On 8 August 2012 15:30, Nick Mathewson wrote:
> Specifically, let me follow up with what I need: I need people with
> good programming taste to read and understand that message, and let me
> know whether you've got any good ideas for fixing it, or whether you
> think my ideas are reasonable. Any
On Wed, Aug 8, 2012 at 2:52 PM, Nick Mathewson wrote:
> On Mon, Aug 6, 2012 at 2:42 PM, Matthieu Nottale
> wrote:
>> Hi.
>>
>> I'm experiencing a deadlock on 2.0.19 while calling bufferevent_free frome
>> thread A, while thread B is in event_base_dispatch.
>>
>
> Ouch. This is a known bug. This
On Wed, Aug 8, 2012 at 11:52 AM, Nick Mathewson wrote:
> On Mon, Aug 6, 2012 at 2:42 PM, Matthieu Nottale
> wrote:
>> Hi.
>>
>> I'm experiencing a deadlock on 2.0.19 while calling bufferevent_free frome
>> thread A, while thread B is in event_base_dispatch.
>>
>
> Ouch. This is a known bug. Thi
On Wed, Aug 8, 2012 at 11:52 AM, Nick Mathewson wrote:
> Ouch. This is a known bug. This fix is going to be hard. I wrote
> about it here:
> http://archives.seul.org/libevent/users/Feb-2012/msg00053.html
Does it make sense to move this to an actual bug on github so it is
easier for others to d
On Mon, Aug 6, 2012 at 2:42 PM, Matthieu Nottale
wrote:
> Hi.
>
> I'm experiencing a deadlock on 2.0.19 while calling bufferevent_free frome
> thread A, while thread B is in event_base_dispatch.
>
Ouch. This is a known bug. This fix is going to be hard. I wrote
about it here:
http://archives.s
On Mon, Aug 6, 2012 at 9:42 PM, Matthieu Nottale <
mnott...@aldebaran-robotics.com> wrote:
> Hi.
>
> I'm experiencing a deadlock on 2.0.19 while calling bufferevent_free frome
> thread A, while thread B is in event_base_dispatch.
>
> Here are the two relevant backtraces:
>
> (gdb) bt
> #0 0xb7fe1
Hi.
I'm experiencing a deadlock on 2.0.19 while calling bufferevent_free
frome thread A, while thread B is in event_base_dispatch.
Here are the two relevant backtraces:
(gdb) bt
#0 0xb7fe1424 in __kernel_vsyscall ()
#1 0xb7d1c48c in pthread_cond_wait@@GLIBC_2.3.2 ()
at
../nptl/sysdeps/
13 matches
Mail list logo
