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
-
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/
[Index of Archives]
[Kernel Newbies]
[Netfilter]
[Bugtraq]
[Photo]
[Stuff]
[Gimp]
[Yosemite News]
[MIPS Linux]
[ARM Linux]
[Linux Security]
[Linux RAID]
[Video 4 Linux]
[Linux for the blind]
[Linux Resources]
