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
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
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
app is playing
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 properly chose a tag that
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
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
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()/close() games for
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
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
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
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
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
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 are
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 that the
> 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
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
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
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
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.
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
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
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
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
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
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 explained it
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.
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 mark missed
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 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 documentation
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 parent.
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, 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 for events on
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
5 is
36 matches
Mail list logo
