Hi Vijay, On Mon, Aug 18, 2008 at 8:54 PM, Vijay Kumar <[EMAIL PROTECTED]> wrote: > Michael Kerrisk <[EMAIL PROTECTED]> wrote: >> On Tue, Aug 12, 2008 at 7:57 PM, Vijay Kumar <[EMAIL PROTECTED]> > wrote: >> > Hi Subrata, >> > this patch adds eventfd counter overflow test cases. >> > >> > Michael, there is a small bug in the eventfd() man page. The man page >> > says that in the select() syscall, exceptfds is set when the counter >> > overflow occurs. But it is readfds/writefds that is set when the >> > counter overflows. POLLERR event in poll() is not equivalent to >> > setting of exceptfds. POLLPRI event in poll() is equivalent to setting >> > of exceptfds. >> >> ( http://www.kernel.org/doc/man-pages/online/pages/man2/eventfd.2.html ) >> >> Thanks for spotting that. I'm not sure why I wrote the text they way >> I did. But now that you point it out, I consider the behavior a >> design error. If I'd correctly described the behavior at the start, I >> would have seen that, and suggested to Davide to change the interface >> so that it uses POLLPRI, not POLLERR, (and thus select() exceptfds) to >> notify the overflow condition. The problem with the current behavior >> is that using select() it is impossible to distinguish the overflow >> condition from the normal case where the eventfd has some non-zero >> value (and is thus both readable and writable). > > 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?
Yes, I suppose that's true. Still, it might have been nicer if an exceptional condition was indicated by select() for this case. > POLLPRI and exceptfds are used for notifying the availability of > out-of-band data in sockets. (It's not their only use though. They also indicate a state change on a pseudoterminal in packet mode.) > 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. Yes, it's true. Still it seems to me it would have been nicer to use POLLPRI/select() exceptfds. As it is, poll() can identify the overflow condition without requiring a read(), but select() cannot. That seems unfortunate. Cheers, Michael -- Michael Kerrisk Linux man-pages maintainer; http://www.kernel.org/doc/man-pages/ man-pages online: http://www.kernel.org/doc/man-pages/online_pages.html Found a bug? http://www.kernel.org/doc/man-pages/reporting_bugs.html ------------------------------------------------------------------------- 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
