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@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. 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@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
