Re: epoll(7) redux

[Michael Kerrisk <mtk.manpages-gM/Ye1E23mwN+BqQ9rBEUg@public.gmane.org>]

Sam Varshavchik wrote:
> 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.


So how about I change:

A2. Yes, and events would be reported to both. However, it is
not recommended.

to:

Yes, and events would be reported to both. However, careful programming
may be needed to do this correctly.

?

Cheers,

Michael

-- 
Michael Kerrisk
Linux man-pages maintainer; http://www.kernel.org/doc/man-pages/
Found a bug? http://www.kernel.org/doc/man-pages/reporting_bugs.html

--
To unsubscribe from this list: send the line "unsubscribe linux-man" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html