A lot of people, including me, were under the mistaken impression
that /dev/epoll, like /dev/poll, provided an efficient way to
retrieve the current readiness state of fd's. I understand from your post
that /dev/epoll's purpose is to retrieve state changes; in other
words, it's exactly like F_SETSIG/F_SETOWN/O_ASYNC except that
the readiness change indications are picked up via an ioctl
rather than via a signal.
A scorecard for the confused (Davide, correct me if I'm wrong):
* API's that allow you to retrieve the current readiness state of
a set of fd's: poll(), select(), /dev/poll, kqueue().
Buzzwords describing this kind of interface: level-triggered, multishot.
* API's that allow you to retrieve *changes* to the readiness state of
a set of fd's: F_SETSIG/F_SETOWN/O_ASYNC + sigtimedwait(), /dev/epoll, kqueue().
Buzzwords describing this kind of interface: edge-triggered, single-shot.
(Note that kqueue is in both camps.)
Er, I guess that means I'll rip up the /dev/epoll support I based on my
/dev/poll code, and replace it with some based on my O_ASYNC code...
- Dan
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/