All of lore.kernel.org
 help / color / mirror / Atom feed
From: Dirk Morris <dmorris@metavize.com>
To: Davide Libenzi <davidel@xmailserver.org>
Cc: Ben Mansell <ben@zeus.com>, Steven Dake <sdake@mvista.com>,
	Linux Kernel Mailing List <linux-kernel@vger.kernel.org>
Subject: Re: epoll reporting events when it hasn't been asked to
Date: Wed, 14 Apr 2004 10:59:27 -0700	[thread overview]
Message-ID: <407D7BFF.4010700@metavize.com> (raw)
In-Reply-To: <Pine.LNX.4.44.0404020717350.1828-100000@bigblue.dev.mdolabs.com>

Davide Libenzi wrote:

>On Fri, 2 Apr 2004, Ben Mansell wrote:
>  
>
>>>If an exception occurs (example a socket is disconnected) the socket
>>>should be removed from the fd list.  There is really no point in passing
>>>in an excepted fd.
>>>      
>>>
>>Is there any difference, speed-wise, between turning off all events to
>>listen to with EPOLL_MOD, and removing the file descriptor with
>>EPOLL_DEL? I had vaguely assumed that the former would be faster
>>(especially if you might later want to resume listening for events),
>>although that was just a guess.
>>    
>>

I'd like to weigh in on this issue as I'm having the same issue as Ben.
My application doesnt consider these to be exceptional events, but 
normal expected events, and thus
I need them to be handled like normal events. (I can explain more off 
list if you'd like)
So I just want to ignore all events for some time and then deal with any 
HUP's or ERR's at the appropriate time.
When I used poll(), I always accomplished this by leaving this fd out of 
the poll fd set.
This wasnt a huge hit because I basically had to rebuild the poll fd set 
at every iteration anyway as it changes rapidly.

Now I'm switching to epoll, and the great thing about the epoll 
interface is I don't have to rebuild the entire fd set at every iteration.
Like Ben, I'd prefer to be able to disable ALL events on a fd descriptor 
for some time, instead of removing it entirely.
Since with poll I had to rebuild the set anyway, this 'disable' feature 
wasnt really useful, but would be a nice-to-have for epoll.
:))







  parent reply	other threads:[~2004-04-14 17:59 UTC|newest]

Thread overview: 21+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2004-04-01 18:25 epoll reporting events when it hasn't been asked to Ben Mansell
2004-04-01 19:28 ` Davide Libenzi
2004-04-01 23:29   ` Steven Dake
2004-04-02  9:04     ` Ben Mansell
2004-04-02 15:22       ` Davide Libenzi
2004-04-02 18:40         ` Is POLLHUP an input-only or bidirectional condition? (was: epoll reporting events when it hasn't been asked to) Jamie Lokier
2004-04-03 12:19           ` Is POLLHUP an input-only or bidirectional condition? Richard Kettlewell
2004-04-03 21:44           ` Is POLLHUP an input-only or bidirectional condition? (was: epoll reporting events when it hasn't been asked to) Davide Libenzi
2004-04-03 22:35             ` Jamie Lokier
2004-04-04  1:28               ` Davide Libenzi
2004-04-04  2:08                 ` Jamie Lokier
2004-04-04  2:49                   ` Davide Libenzi
2004-04-04 18:51               ` Ben Mansell
2004-04-04 19:41                 ` Davide Libenzi
2004-04-04 20:24                 ` Jamie Lokier
2004-04-14 17:59         ` Dirk Morris [this message]
2004-04-14 19:39           ` epoll reporting events when it hasn't been asked to Jamie Lokier
2004-04-14 20:21             ` Dirk Morris
2004-04-14 21:48               ` Jamie Lokier
  -- strict thread matches above, loose matches on Subject: below --
2004-04-01 16:54 Ben
2004-04-01 17:51 ` Davide Libenzi

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=407D7BFF.4010700@metavize.com \
    --to=dmorris@metavize.com \
    --cc=ben@zeus.com \
    --cc=davidel@xmailserver.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=sdake@mvista.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.