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?

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.

Regards,
Vijay



-------------------------------------------------------------------------
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

Reply via email to