Lines Matching +full:foo +full:- +full:queue

8 	--Deleted obsoleted interface, just refer to manpages for user interface.
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,
26    select()-able.  Yes, root can bump the per-process fd limit and yes, users
29    spaces is thus sensible.  The current design is what user-space developers
32    thousand times is silly.  If we can implement user-space's preferences 
33    cleanly--and we can, the idr layer makes stuff like this trivial--then we 
37    item to block on, which is mapped to a single queue of events.  The single
38    fd returns all watch events and also any potential out-of-band data.  If
41    - There would be no way to get event ordering.  Events on file foo and
43      which happened first.  A single queue trivially gives you ordering.  Such
47    - We'd have to maintain n fd's and n internal queues with state,
49      queue is the data structure that makes sense.
51    - User-space developers prefer the current API.  The Beagle guys, for
55    - No way to get out of band data.
57    - 1024 is still too low.  ;-)
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
66    process can easily want more than one queue.
70 A: The poor user-space interface is the second biggest problem with dnotify.
73    file descriptor-based one that allows basic file I/O and poll/select.