On Tue, 26 Feb 2008, Michael Kerrisk wrote:
> Davide Libenzi wrote:
> > On Sun, 28 Oct 2007, David Schwartz wrote:
> >
> >> Eric Dumazet wrote:
> >>
> >>> Events are not necessarly reported "by descriptors". epoll uses an opaque
> >>> field provided by the user.
> >>>
> >>> It's up to the user to
Davide Libenzi wrote:
> On Sun, 28 Oct 2007, David Schwartz wrote:
>
>> Eric Dumazet wrote:
>>
>>> Events are not necessarly reported "by descriptors". epoll uses an opaque
>>> field provided by the user.
>>>
>>> It's up to the user to properly chose a tag that will makes sense
>>> if the user
>
Willy Tarreau wrote:
On Sat, 27 Oct 2007, Marc Lehmann wrote:
Please provide some code to illustrate one exact problem you have.
// assume there is an open epoll set that listens for events on fd 5
if (fork () = 0)
{
close (5);
// fd 5 is now removed from the epoll set
On Sun, 28 Oct 2007, David Schwartz wrote:
>
> Eric Dumazet wrote:
>
> > Events are not necessarly reported "by descriptors". epoll uses an opaque
> > field provided by the user.
> >
> > It's up to the user to properly chose a tag that will makes sense
> > if the user
> > app is playing dup()/cl
Eric Dumazet wrote:
> Events are not necessarly reported "by descriptors". epoll uses an opaque
> field provided by the user.
>
> It's up to the user to properly chose a tag that will makes sense
> if the user
> app is playing dup()/close() games for example.
Great. So the only issue then is tha
On Sat, 27 Oct 2007, David Schwartz wrote:
> I don't see how that can be. Suppose I add fd 8 to an epoll set.
> Suppose fd
> 5 is a dup of fd 8. Now, I close fd 8. How can fd 8 remain in my epoll set,
> since there no longer is an fd 8? Events on files registered for epoll
> notification ar
David Schwartz a écrit :
6) Epoll removes the file from the set, when the *kernel* object gets
closed (internal use-count goes to zero)
With that in mind, how can the code snippet above trigger a removal from
the epoll set?
I don't see how that can be. Suppose I add fd 8 to an epoll
> 6) Epoll removes the file from the set, when the *kernel* object gets
>closed (internal use-count goes to zero)
>
> With that in mind, how can the code snippet above trigger a removal from
> the epoll set?
I don't see how that can be. Suppose I add fd 8 to an epoll set.
Suppose fd
On Sat, 27 Oct 2007, Willy Tarreau wrote:
> On Sat, Oct 27, 2007 at 09:59:07AM -0700, Davide Libenzi wrote:
> > On Sat, 27 Oct 2007, Marc Lehmann wrote:
> >
> > > > Please provide some code to illustrate one exact problem you have.
> > >
> > >// assume there is an open epoll set that listens
On Sat, Oct 27, 2007 at 09:59:07AM -0700, Davide Libenzi wrote:
> On Sat, 27 Oct 2007, Marc Lehmann wrote:
>
> > > Please provide some code to illustrate one exact problem you have.
> >
> >// assume there is an open epoll set that listens for events on fd 5
> >if (fork () = 0)
> > {
On Sat, 27 Oct 2007, Marc Lehmann wrote:
> > Please provide some code to illustrate one exact problem you have.
>
>// assume there is an open epoll set that listens for events on fd 5
>if (fork () = 0)
> {
>close (5);
>// fd 5 is now removed from the epoll set of the
On Sat, Oct 27, 2007 at 12:23:52PM +0200, Eric Dumazet <[EMAIL PROTECTED]>
wrote:
> >Q6 Will the close of an fd cause it to be removed from all epoll
> >sets automatically?
> >A6 Yes.
>
> Answer : epoll documentation cannot explain the full semantic of file
epoll documentat
Marc Lehmann a écrit :
On Sat, Oct 27, 2007 at 11:22:25AM +0200, Eric Dumazet <[EMAIL PROTECTED]>
wrote:
If such a bug exists on your kernel, please fill a complete bug report,
giving details.
As this behaviour is clearly documented in the epoll manpage, why do you
think it is a bug? I think
On Sat, Oct 27, 2007 at 11:22:25AM +0200, Eric Dumazet <[EMAIL PROTECTED]>
wrote:
> >Well, it behaves like documented, which is the problem. You admit you
> >don't understand the problem or the documentation, so again, no need to
> >insult me.
>
> Hum... I will update my english vocabulary and ma
Marc Lehmann a écrit :
On Sat, Oct 27, 2007 at 10:23:17AM +0200, Eric Dumazet <[EMAIL PROTECTED]>
wrote:
In this case, the parent process works fine until the child closes fds,
after which the fds become unarmed in the parent too. This works as
I have no idea what exact problem you have.
W
On Sat, Oct 27, 2007 at 10:23:17AM +0200, Eric Dumazet <[EMAIL PROTECTED]>
wrote:
> > In this case, the parent process works fine until the child closes fds,
> > after which the fds become unarmed in the parent too. This works as
>
> I have no idea what exact problem you have.
Well, I explain
Marc Lehmann a écrit :
Hi!
I ran into what I see as unsolvable problems that make epoll useless as a
generic event mechanism.
I recently switched to libevent as event loop, and found that my programs
work fine when it is using select or poll, but work eratically or halt
when using epoll.
The r
Hi!
I ran into what I see as unsolvable problems that make epoll useless as a
generic event mechanism.
I recently switched to libevent as event loop, and found that my programs
work fine when it is using select or poll, but work eratically or halt
when using epoll.
The reason as I found out is t
18 matches
Mail list logo
