Re: [patch] inotify.

[Robert Love <rml@novell.com>]

On Tue, 2005-06-21 at 12:29 +1000, Neil Brown wrote:

> There may well be other good arguments against 'fd's, but I'm trying
> to point out that this isn't one of them, and so shouldn't appear in
> this part of the FAQ.

You raise a good point, although one could argue that raising the fd
limit is not necessarily feasible.

There are other good arguments.  With a single fd, there is a single
item to block on, which is mapped to a single queue of events.  The
single fd returns all watch events and also any potential out-of-band
data.  If every fd was a separate watch,

	- There would be no way to get event ordering.  Events on file
	  foo and file bar would pop poll() on both fd's, but there
	  would be no way to tell which happened first.  A single queue
	  trivially gives you ordering.
	- We'd have to maintain n fd's and n internal queues with state,
	  versus just one.  It is a lot messier in the kernel.
	- User-space developers prefer the current API.  The Beagle
	  guys, for example, love it.  Trust me, I asked.  It is not
	  a surprise: Who'd want to manage and block on 1000 fd's?
	- You'd have to manage the fd's, as an example: call close()
	  when you received a delete event.
	- No way to get out of band data.
	- 1024 is still too low.  ;-)

When you talk about designing a file change notification system that
scales to 1000s of directories, juggling 1000s of fd's just does not
seem the right interface.  It is too heavy.

I should add this to the FAQ, yes.  ;-)

	Robert Love