Re: epoll(7) redux

[Sam Varshavchik <mrsam-W1w4QoW4mIDgLSHwZvcCBg@public.gmane.org>]

[-- Attachment #1: Type: text/plain, Size: 1601 bytes --]

Davide Libenzi writes:

> On Wed, 9 Apr 2008, Michael Kerrisk wrote:
> 
>> On Wed, Apr 9, 2008 at 1:07 PM, Sam Varshavchik <mrsam-W1w4QoW4mIDgLSHwZvcCBg@public.gmane.org> wrote:
>> > Q2
>> >
>> >   Can two epoll sets wait for the same file descriptor? If so, are events
>> > reported to both epoll file descriptors?
>> >
>> > A2
>> >
>> >   Yes, and events would be reported to both. However, it is not recommended.
>> >
>> > =========
>> >
>> > It's not clear what "not recommended" means. Furthermore, I don't think
>> > there's anything wrong with two epoll file descriptors waiting for different
>> > events on the same file descriptor. One's waiting for POLLIN, the other for
>> > POLLOUT. What's wrong with that?
>> 
>> Perhaps Davide has some thought to offer here?
> 
> You can do it. No problem as far as epoll goes. The "recommended" bit was 
> more because it is very easy to get things wrong from an application 
> perspective POV, when doing that.
> In the case above, first POLLOUT is "almost" always signaled, so you'll 
> receive continuous events over there. Second, if both events shows up at 
> the same time (say in two different threads) and you do not take care of 
> it, you'll end up handling the same fd, at the same time, in two different 
> threads.

That's what I had in mind. One thread has the fd in its epoll fd for POLLIN, 
and handles the read aspect of it. Another thread puts the fd into a 
different epoll fd, for POLLOUT, and handles the writing aspect of it. It 
shouldn't be too difficult for both threads to correctly implement their 
corresponding semantics.


[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]