On Thu, 8 Mar 2007, Davide Libenzi wrote:
>
> This patch, if you get a POLLIN, you have a signal to read for sure (well,
> unless you another thread/task reads it before you - but that's just
> somthing you have to take care). There is not explicit check for
> O_NONBLOCK now, but a zero timeout would do exactly the same thing.
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.
Linus
-
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/
