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
17 matches
Mail list logo
