Message-ID: <407D9D2F.3010901@metavize.com>
Date: Wed, 14 Apr 2004 13:21:03 -0700
From: Dirk Morris <dmorris@metavize.com>
User-Agent: Mozilla Thunderbird 0.5 (X11/20040306)
MIME-Version: 1.0
To: Jamie Lokier <jamie@shareable.org>
CC: Davide Libenzi <davidel@xmailserver.org>, 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
References: <Pine.LNX.4.44.0404020717350.1828-100000@bigblue.dev.mdolabs.com> <407D7BFF.4010700@metavize.com> <20040414193947.GE12105@mail.shareable.org>
In-Reply-To: <20040414193947.GE12105@mail.shareable.org>
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
Sender: linux-kernel-owner@vger.kernel.org
Content-Length: 1317
Lines: 39

Jamie Lokier wrote:

>Dirk Morris wrote:
>  
>
>>I need them to be handled like normal events. (I can explain more off 
>>list if you'd like)
>>    
>>
>
>Did you read my explanation of how to do this using the present epoll
>behaviour using _fewer_ syscalls than you are asking for?
>  
>
Ah yes, I just went back and read it.
 From what I understand you're proposing to remove the fd from the set 
lazily instead of immediately.
Which will save system calls in the cases were the HUP/ERR condition 
does not occur during the 'disabled' time.

In my case, which you may choose to disregard, this condition is not 
irregular or in any way a special case.
So the revision you have proposed is just an optimization.
You could even use this same optimization with the disable feature 
(disable it lazily) and get even better performance with the same number 
of syscalls you proposed.

I see no downside, except that it no longer conforms to the semantics of 
poll and select.
Whether or not its worth it to deviate from this behavior over such a 
detail, I don't know. :)


-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/