On Wed, 21 May 2008, Michael Kerrisk wrote: > > > 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. > > ? Looks OK to me. - Davide -- 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
