On Thu, 8 Mar 2007, Linus Torvalds wrote: > You missed David's worry, I think. > > Not only is POLLIN potentially an edge event (depending on the interface > you use to fetch it), but even as a level-triggered one you generally want > to read as much as possible per POLLIN event, and go back to the event > loop only when you get EAGAIN. > > So that's in addition to the read/signal race with other > threads/processes. > > You solved it by having a separate system call, but since it's a regular > file descriptor, why have a new system call at all, and not just make it > be a "read()"? In which case you definitely want O_NONBLOCK support. > > The UNIX philosophy is often quoted as "everything is a file", but that > really means "everything is a stream of bytes". > > In Windows, you have 15 different versions of "read()" with sockets and > files and pipes all having strange special cases and special system calls. > That's not the UNIX way. It should be just a "read()", and then people can > use general libraries and treat all sources the same. > > For example, the main select/poll/epoll loop may be the one doing all the > reading, and then pass off "full buffers only" to the individual per-fd > "action routines". And that kind of model really very fundamentally wants > an fd to be an fd to be an fd - not "some file descriptors need > 'read_from_sigfd()', and some file descriptors need 'read()', and some > file descriptors need 'recvmsg()'" etc. > > So I think you should get rid of signalfd_dequeue(), and just replace it > with a "read()" function.
The reason for the special function, was not to provide a non-blocking behaviour with zero timeout (that just a side effect), but to read the siginfo. I was all about using read(2) (and v1 used it), but when you have to transfer complex structures over it, it becomes hell. How do you cleanly compat over a f_op->read callback for example? - Davide - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/