On Tue, 19 Aug 2008, Vijay Kumar wrote: > After returning from select(), the application will anyway read() the > eventfd, and the overflow can be identified from the read value. So it > is not really necessary to use exceptfds, right? > > POLLPRI and exceptfds are used for notifying the availability of > out-of-band data in sockets. They cannot be notified through readfds > because, read() will not provide the out-of-band data, and could > potentially block. In this case, we really need exceptfds, to > distinguish between the availability of normal data and out-of-band > data. > > But this type of classification is not required for eventfd. Since > after select() notifies through readfds, in both overflow case and > non-overflow case, the application can call read() without blocking.
Sorry for the delay, I was in vacation mode. I agree with this. Unfortunately, fitting the eventfd model to a structure that has been essentially designed for sockets is not easy. There's no OOB data with eventfd and a read(2) will clear both (even considering the counter topping the max value as OOB data). That, and the fact that select(2) is a prehistoric interface, does not disturb my sleep that much. - Davide ------------------------------------------------------------------------- This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK & win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100&url=/ _______________________________________________ Ltp-list mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/ltp-list
