t
> Subject: Re: [Libevent-users] epoll erros
>
> On Fri, Oct 22, 2010 at 4:25 PM, Nicholas Marriott
> wrote:
> > 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
> > th
Hi
On Sun, Oct 24, 2010 at 01:03:25PM -0400, Nick Mathewson wrote:
> On Fri, Oct 22, 2010 at 4:25 PM, Nicholas Marriott
> wrote:
> > 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->
On Fri, Oct 22, 2010 at 4:25 PM, Nicholas Marriott
wrote:
> 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 :-).
I think you're ri
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
t 12:20 AM, Gilad Benjamini
> wrote:
> >> -Original Message-
> >> From: Nick Mathewson
> >> Sent: Tuesday, September 21, 2010 7:43 PM
> >> To: libevent-us...@freehaven.net
> >> Subject: Re: [Libevent-users] epoll erros
> >> ...
> >
> -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
>
>
us...@freehaven.net
>> Subject: Re: [Libevent-users] epoll erros
>>
> ...
>> It won't catch attempts to manually reassign the event's ev_events
>> while the event is added. I sure hope nobody is doing that. Don't
>> touch struct event's fields by
> -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
>
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
?]
On Fri, Oct 22, 2010 at 12:20 AM, Gilad Benjamini
wrote:
>> -Original Message-
>> From: Nick Mathewson
>> Sent: Tuesday, September 21, 2010 7:43 PM
>> To: libevent-us...@freehaven.net
>> Subject: Re: [Libevent-users] epoll erros
>> ...
>>
>&
On Wed, Sep 22, 2010 at 11:53 AM, Gilad Benjamini
wrote:
>>
>> 2010/9/21 Gilad Benjamini :
>> [...]
>> > Any chance you can hmake something out of the attached log ?
>>
>> That's pretty helpful! It's almost but not quite enough information
>> to figure out what's up here. There are a couple of
>
> 2010/9/21 Gilad Benjamini :
> [...]
> > Any chance you can hmake something out of the attached log ?
>
> That's pretty helpful! It's almost but not quite enough information
> to figure out what's up here. There are a couple of epoll debugging
> messages that don't give enough detail.
>
>
2010/9/21 Gilad Benjamini :
[...]
> Any chance you can make something out of the attached log ?
That's pretty helpful! It's almost but not quite enough information
to figure out what's up here. There are a couple of epoll debugging
messages that don't give enough detail.
I just added a couple
On Fri, Sep 17, 2010 at 3:06 PM, Gilad Benjamini
wrote:
>> The first thing to do here is to use event_enable_debug_mode() to have
>> libevent track event adds/deletes/etc to make sure that there's
>> nothing screwy going on there.
(Did this turn anything up? You don't need to build with any spec
> The first thing to do here is to use event_enable_debug_mode() to have
> libevent track event adds/deletes/etc to make sure that there's
> nothing screwy going on there.
>
Here is the chain of events I was able to identify
- An event for fd 14 is created
- At some later point, my code deletes th
> The first thing to do here is to use event_enable_debug_mode() to have
> libevent track event adds/deletes/etc to make sure that there's
> nothing screwy going on there.
>
Beside calling event_enable_debug_mode I understand I have to turn on
debugging.
How would I do that ? configure --enable-
On Thu, Sep 16, 2010 at 2:59 PM, Gilad Benjamini
wrote:
> My Linux code, which uses libevent 2.0.x occasionally prints these error
> messages
> Epoll ADD on fd 14 failed. Old events were 0; read change was 1 (add);
> write change was 0 (none).: File exists
> When they appear, it can be as freq
My Linux code, which uses libevent 2.0.x occasionally prints these error
messages
Epoll ADD on fd 14 failed. Old events were 0; read change was 1 (add);
write change was 0 (none).: File exists
When they appear, it can be as frequent as once a second.
Can someone shed some light on what the is
23 matches
Mail list logo