Re: [patch 6/9] signalfd/timerfd v1 - timerfd core ...

[Linus Torvalds <torvalds@linux-foundation.org>]

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