Is it OK to poll() a device file descriptor

Is it OK to poll() a device file descriptor

Shachar Shemesh shachar at shemesh.biz
Tue Jun 18 20:42:24 IDT 2013


On 18/06/13 17:43, Elazar Leibovich wrote:
> Try to open /dev/null, and then to poll the file descriptor. Neither
> in the man page nor in the standard I see anything preventing you to
> poll on /dev/null, yet, it does not work on Mac OS X. You get a POLLNVAL.
>
Under Linux, whether you can poll (epoll, select) a character device
depends on the device's implementation. If the device implements it,
then you can. If not, you can't.

Under Linux, the device driver's implementer implements one callback,
and the kernel uses that to allow select, poll and epoll (plus the "p"
variants of the above) all at once. On Mac OS X, however, the BUGS line
Oleg pointed to does not appear in the select syscall interface, which
means that it might be possible to select a device file descriptor.

Our of curiosity, however, why would you want to poll /dev/null?

Shachar
> Run the following:
>
> https://gist.github.com/elazarl/5805848
>
> #include <stdio.h>
> #include <poll.h>
>
>  
> #include <fcntl.h>
>  
> int main() {
>
> int fd = open("/dev/null", O_WRONLY);
>
> struct pollfd pollfds = { fd, POLLOUT, 0 };
>
> if (fd < 0) {
>
> perror("open");
>
> return 1;
> }
> if (poll(&pollfds, 1, -1) < 0) {
>
> perror("poll");
>
> return 2;
> }
> if (pollfds.revents == POLLNVAL) {
>
> puts("huh? why poll({/dev/null, POLLOUT, 0}, 1) returns POLLNVAL?");
>
> }
> if (pollfds.revents == POLLOUT) {
>
> puts("working as expected");
>
> }
> return 0;
>
> }
> Is there anything I'm missing? Or is it a real vaguely implemented
> corner of the standard.
> If it is, I'll be glad to see a list of supported/unsupported platforms,
>
> as well as list of other corner cases (for instance, POLLHUP may or
> may be received on EOF).
>
>
>
> _______________________________________________
> Linux-il mailing list
> Linux-il at cs.huji.ac.il
> http://mailman.cs.huji.ac.il/mailman/listinfo/linux-il

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.cs.huji.ac.il/pipermail/linux-il/attachments/20130618/52b07229/attachment-0001.html>


More information about the Linux-il mailing list