Lines Matching +full:way +full:- +full:select

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 
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
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,
51    - User-space developers prefer the current API.  The Beagle guys, for
53      to manage and block on 1000 fd's via select?
55    - No way to get out of band data.
57    - 1024 is still too low.  ;-)
65    need not be a one-fd-per-process mapping; it is one-fd-per-queue and a
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.