On Sat, 10 Mar 2007, Nicholas Miell wrote:
> >
> > I'd actually much rather do POSIX timers the other way around: associate a
> > generic notification mechanism with the file descriptor, and then
> > implement posix_timer_create() on top of timerfd. Now THAT sounds like a
> > clean unix-like interface ("everything is a file") and would imply that
> > you'd be able to do the same kind of notification for any file descriptor,
> > not just timers.
> >
>
> But timers aren't files or even remotely file-like
What do you think "a file" is?
In UNIX, a file descriptor is pretty much anything. You could say that
sockets aren't remotely file-like, and you'd be right. What's your point?
If you can read on it, it's a file.
And the real point of the whole signalfd() is that there really *are* a
lot of UNIX interfaces that basically only work with file descriptors. Not
just read, but select/poll/epoll.
They currently have just one timeout, but the thing is, if UNIX had just
had "timer file descriptors", they'd not need even that one. And even with
the timeout, Davide's patch actually makes for a *better* timeout than the
ones provided by select/poll/epoll, exactly because you can do things like
repeating timers and absolute time etc.
Much more naturally than the timer interface we currently have for those
system calls.
The same goes for signals. The whole "pselect()" thing shows that signals
really *should* have been file descriptors, and suddenly you don't need
"pselect()" at all.
So the "not remotely file-like" is not actually a real argument. One of
the big *points* of UNIX was that it unified a lot under the general
umbrella of a "file descriptor". Davide just unifies even more.
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/
