Lines Matching refs:a
12 The library provides much more than a simple abstraction over different I/O polling mechanisms:
13 'handles' and 'streams' provide a high level abstraction for sockets and other entities;
16 Here is a diagram illustrating the different parts that compose libuv and what subsystem they
33 - A TCP server handle that gets its connection callback called every time there is a new connection.
35 Requests represent (typically) short-lived operations. These operations can be performed over a
36 handle: write requests are used to write data on a handle; or standalone: getaddrinfo requests
37 don't need a handle they run directly on the loop.
44 operations, and it's meant to be tied to a single thread. One can run multiple event loops
45 as long as each runs in a different thread. The libuv event loop (or any other API involving
51 on Windows. As part of a loop iteration the loop will block waiting for I/O activity on sockets
56 stages of a loop iteration:
66 for a time before the loop's concept of *now* get their callbacks called.
69 when is a loop considered to be *alive*? If a loop has active and ref'd handles, active
73 most part. There are cases, however, in which calling such a callback is deferred for the next
94 in the previous step. All I/O related handles that were monitoring a given file descriptor
95 for a read or write operation get their callbacks called at this point.
100 #. Close callbacks are called. If a handle was closed by calling :c:func:`uv_close` it will
106 So if a timer became due while other timers were being processed, it won't be run until
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.
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
132 libuv currently uses a global thread pool on which all loops can queue work. 3 types of
