Lines Matching refs:I
8 around the event-driven asynchronous I/O model.
12 The library provides much more than a simple abstraction over different I/O polling mechanisms:
14 cross-platform file I/O and threading functionality is also provided, amongst other things.
40 The I/O loop
43 The I/O (or event) loop is the central part of libuv. It establishes the content for all I/O
48 The event loop follows the rather usual single threaded asynchronous I/O approach: all (network)
49 I/O is performed on non-blocking sockets which are polled using the best mechanism available
51 on Windows. As part of a loop iteration the loop will block waiting for I/O activity on sockets
53 (readable, writable hangup) so handles can read, write or perform the desired I/O operation.
72 #. Pending callbacks are called. All I/O callbacks are called right after polling for I/O, for the
74 loop iteration. If the previous iteration deferred any I/O callback it will be run at this point.
80 the loop will block for I/O.
82 #. Poll timeout is calculated. Before blocking for I/O the loop calculates for how long it should
93 #. The loop blocks for I/O. At this point the loop will block for I/O for the duration calculated
94 in the previous step. All I/O related handles that were monitoring a given file descriptor
98 loop has blocked for I/O. Check handles are essentially the counterpart of prepare handles.
115 libuv uses a thread pool to make asynchronous file I/O operations possible, but
116 network I/O is **always** performed in a single thread, each loop's thread.
123 File I/O
126 Unlike network I/O, there are no platform-specific file I/O primitives libuv could rely on,
127 so the current approach is to run blocking file I/O operations in a thread pool.
129 For a thorough explanation of the cross-platform file I/O landscape, check out
