[Libevent-users] gevent 0.13.2 released

Hi! I'm happy to announce that Gevent 0.13.2 is released with a number of bug fixes and a new gevent.httplib module that implements fast HTTP client - wrapper around libevent-http. What is it? gevent is a coroutine-based Python networking library that uses greenlet to provide a high-level synchr

Re: [Libevent-users] Re: libevent-2.0.8-rc/evdns.c:2672: Assertion (req)->handle && (req)->handle->current_req == (req) failed in evdns_cancel_request

On Tue, Nov 16, 2010 at 6:54 PM, Nick Mathewson wrote: >> Thanks!  I'm trying to reproduce this so I can see whether my fix >> ideas work, but I'm not having a lot of luck.  Any chance of a quick >> test program so I can reproduce this crash? > > There's a possible fix in my github repository > (g

Re: [Libevent-users] Re: libevent-2.0.8-rc/evdns.c:2672: Assertion (req)->handle && (req)->handle->current_req == (req) failed in evdns_cancel_request

On Thu, Nov 4, 2010 at 9:10 PM, Nick Mathewson wrote: > Assuming that it now crashes in a different place from where it used > to crash -- that is, at ASSERT_VALID_REQUEST in evdns_cancel, I've got > an updated patch, attached below.  Third time is maybe the charm. Yeah, it seems to work now with

Re: [Libevent-users] Re: libevent-2.0.8-rc/evdns.c:2672: Assertion (req)->handle && (req)->handle->current_req == (req) failed in evdns_cancel_request

On Thu, Nov 4, 2010 at 1:24 AM, Nick Mathewson wrote: >> You free req->handle and then access it. > > Ugh.  What if we move "req->handle->current_req =NULL" to *above* that "if" ? Still crashes. *** To unsubscribe, send an e-mail

Re: [Libevent-users] Re: libevent-2.0.8-rc/evdns.c:2672: Assertion (req)->handle && (req)->handle->current_req == (req) failed in evdns_cancel_request

On Wed, Nov 3, 2010 at 10:38 PM, Nick Mathewson wrote: >> Probably the right answer here is to add a reference count to the >> request, and not actually free it until the reference count hits zero. > > Actually, we can go even simpler.  Here's the patch I've got in mind. > > There may be better wa

[Libevent-users] Re: libevent-2.0.8-rc/evdns.c:2672: Assertion (req)->handle && (req)->handle->current_req == (req) failed in evdns_cancel_request

omething, but why go through reply_schedule_callback at all? Why not call the user's callback immediately and avoid extra step which makes cancel() unsafe? On Wed, Nov 3, 2010 at 12:47 PM, Denis Bilenko wrote: > I've been working on making gevent use libevent's getaddrinfo and > occa

[Libevent-users] libevent-2.0.8-rc/evdns.c:2672: Assertion (req)->handle && (req)->handle->current_req == (req) failed in evdns_cancel_request

I've been working on making gevent use libevent's getaddrinfo and occasionally get the above message in one of the test cases. What could trigger it? How can I avoid it? I don't call evdns_getaddrinfo_cancel if the callback was already executed, so I wonder how could I arrive at invalid request?

[Libevent-users] ANN: Gevent 0.13.1 released

Hi! I'm happy to announce that Gevent 0.13.1 is released. What is it? gevent is a coroutine-based Python networking library that uses greenlet to provide a high-level synchronous API on top of libevent event loop. Features include: * Fast event loop based on libevent. * Lightweight execution u

Re: [Libevent-users] event_add fails with ENOENT when on epoll

libevent "just work" here? For example, would it be wrong to intercept ENOENT in event_add() then delete the existing events and retry? On Wed, Apr 21, 2010 at 12:20 AM, Nick Mathewson wrote: > On Mon, Apr 19, 2010 at 11:24 PM, Denis Bilenko > wrote: >> Hi, >> &g

[Libevent-users] event_add fails with ENOENT when on epoll

Hi, I've run into an issue where event_add() fails with ENOENT. This happens when a socket reuses a descriptor that was recently closed and was used before with another event. The details are below. The question I have is - what are the ways to work around this? Thanks, Denis. http://www.gevent.