Re: epoll(7) redux

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



Davide Libenzi writes:

On Wed, 9 Apr 2008, Michael Kerrisk wrote:

On Wed, Apr 9, 2008 at 1:07 PM, Sam Varshavchik <mrsam@xxxxxxxxxxxxxxx> 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: pgpzvlzuiWlgB.pgp
Description: PGP signature


[Index of Archives]     [Kernel Documentation]     [Netdev]     [Linux Ethernet Bridging]     [Linux Wireless]     [Kernel Newbies]     [Security]     [Linux for Hams]     [Netfilter]     [Bugtraq]     [Yosemite News]     [MIPS Linux]     [ARM Linux]     [Linux RAID]     [Linux Admin]     [Samba]

  Powered by Linux