I don't know. I did the debugging on this about 3 weeks ago and my
cache is very cold at the moment.
Shouldn't bufferevent_disable_hard_(bufev, EV_READ|EV_WRITE) have
cleared any fd out of the evmap and epoll?
Looking at be_socket_disable:
if (event & EV_READ) {
if (event_del(&bufev->ev_read) == -1)
return -1;
}
/* Don't actually disable the write if we are trying to connect. */
if ((event & EV_WRITE) && ! bufev_p->connecting) {
if (event_del(&bufev->ev_write) == -1)
return -1;
}
In particular the '&& !connecting' part. Seems related to the
occurrence of these on fds that time out.
On Tue, Feb 19, 2013 at 4:30 PM, Catalin Patulea <catal...@google.com> wrote:
> On Tue, Feb 19, 2013 at 4:17 PM, Nick Mathewson <ni...@freehaven.net> wrote:
>> But the patch isn't quite optimal for that -- we should do the
>> bufferevent_setfd() before we close the socket, not after. That way
>> there's never a non-deleted event that refers to the fd.
> The idea with doing the setfd there was in the case where evcon->fd ==
> -1 but the bufferevent has an fd.
>
> Why is there a copy of the fd in evcon? Why not use
> bufferevent_getfd(evcon->bufev)?
>
>> How does the attached patch look to you? Does it work as well/any better?
> I'll see about canarying it and will reply once it's been running for a while.
***********************************************************************
To unsubscribe, send an e-mail to majord...@freehaven.net with
unsubscribe libevent-users in the body.
