Lines Matching refs:fd

12 Q: What is the design decision behind not tying the watch to the open fd of
21 Q: What is the design decision behind using an-fd-per-instance as opposed to
22    an fd-per-watch?
24 A: An fd-per-watch quickly consumes more file descriptors than are allowed,
25    more fd's than are feasible to manage, and more fd's than are optimally
26    select()-able.  Yes, root can bump the per-process fd limit and yes, users
31    fd and no twiddling with fd limits.  Initializing an inotify instance two
36    There are other good arguments.  With a single fd, there is a single
38    fd returns all watch events and also any potential out-of-band data.  If
39    every fd was a separate watch,
42      file bar would pop poll() on both fd's, but there would be no way to tell
47    - We'd have to maintain n fd's and n internal queues with state,
53      to manage and block on 1000 fd's via select?
60    scales to 1000s of directories, juggling 1000s of fd's just does not seem
64    juggle more than one queue and thus more than one associated fd.  There
65    need not be a one-fd-per-process mapping; it is one-fd-per-queue and a
74    Obtaining the fd and managing the watches could have been done either via a