In libevent-2.0.8-rc, buffer.c: evbuffer_add()
Code was:
1470 in evbuffer_add(struct evbuffer *buf, const void *data_in, size_t
datlen)
1471 {
1505 } else if ((size_t)chain->misalign >= datlen && !CHAIN_PINNED(chain)) {
1551 }
I think it does not make full use of misal
I think something needs to walk the file->f_ep_links list on close() and
remove any epitems where epi->ffd->fd is the fd being closed from the
tree in epi->ep.
I don't have a Linux box to try this on though :-).
On Fri, Oct 22, 2010 at 09:15:26PM +0100, Nicholas Marriott wrote:
> It also looks
It also looks to me like eventpoll_release is not called until the
struct file is released (ie all refs are gone), NOT when the fd is
closed.
So this means that because it is dup()d it remains on the tree even
after close().
Then because you dup() it again _to the same target fd_, when you try to
On a quick look it seems to me like epoll keys the tree on the epoll fd
by both underlying struct file and the file descriptor itself, so it
should work with dup()d fds.
On Fri, Oct 22, 2010 at 08:42:13PM +0100, Nicholas Marriott wrote:
> If this is right it seems really stupid and inconvenient.
> Apparently, the Linux kernel associates epoll state with files in such
> a way that the epoll state is shared across dup()'d fds. I'll read the
> kernel source a little more to be sure of what's happening. I've
> attached a variant of my test code to reproduce this. Thanks, Gilad,
> for all y
If this is right it seems really stupid and inconvenient. Sounds more
like a bug to me.
I add dup()d fds to libevent and haven't had any complaints from Linux
users. Although I don't remove and add them (or read and write from both
at the same time, I think).
dup()d fds definitely seems to work w
On Fri, Oct 22, 2010 at 1:54 PM, Nick Mathewson wrote:
[...]
> Actually, straceing the application up to the point where it gets its
> first message like
>
> [warn] Epoll ADD(1) on fd 13 failed. Old events were 0; read change
> was 1 (add); write change was 0 (none): File exists
>
> would proba
Maybe not too much help but it seems like strace would answer
possibilities 1, 2 and 3, that's how I typically track what is happening
with epoll inside libevent.
On Fri, Oct 22, 2010 at 01:38:45PM -0400, Nick Mathewson wrote:
> [summary: Nick looks for a bug, and finds only weirdness. But I thi
> -Original Message-
> From: owner-libevent-us...@freehaven.net [mailto:owner-libevent-
> us...@freehaven.net] On Behalf Of Nick Mathewson
> Sent: Friday, October 22, 2010 11:19 AM
> To: libevent-us...@freehaven.net
> Subject: Re: [Libevent-users] epoll erros
>
> D'oh. I should have been m
On Fri, Oct 22, 2010 at 2:12 PM, Gilad Benjamini
wrote:
>> -Original Message-
>> From: owner-libevent-us...@freehaven.net [mailto:owner-libevent-
>> us...@freehaven.net] On Behalf Of Nick Mathewson
>> Sent: Friday, October 22, 2010 10:39 AM
>> To: libevent-us...@freehaven.net
>> Subject: R
> -Original Message-
> From: owner-libevent-us...@freehaven.net [mailto:owner-libevent-
> us...@freehaven.net] On Behalf Of Nick Mathewson
> Sent: Friday, October 22, 2010 10:39 AM
> To: libevent-us...@freehaven.net
> Subject: Re: [Libevent-users] epoll erros
>
...
> It won't catch attempt
On Fri, Oct 22, 2010 at 1:38 PM, Nick Mathewson wrote:
[...]
> 4 is conceivable under a couple of weird circumstances. Might there
> be more than one event_base in the application, so that fd 13 is
> actually getting added/removed from separate event_bases? Might there
> be multithreading issue
[summary: Nick looks for a bug, and finds only weirdness. But I think
we're on to something, and we *are* making progress. Big find: there
doesn't seem to be anything wrong with the changlist logic; something
weird is up with epoll here. Could other people please help me look
into this?]
On Fri,
13 matches
Mail list logo
