Lines Matching refs:readiness
32 `&self`. This supports concurrent waiters with a different readiness interest.
49 /// Awaits for any readiness event included in `interest`. Returns a
50 /// `ReadyEvent` representing the received readiness event.
51 async fn readiness(&self, interest: mio::Ready) -> io::Result<ReadyEvent>;
53 /// Clears resource level readiness represented by the specified `ReadyEvent`
62 receives readiness from the OS once the ready state **changes**. The I/O driver
63 must track each resource's known readiness state. This helps prevent syscalls
66 A call to `readiness()` checks if the currently known resource readiness
67 overlaps with `interest`. If it does, then the `readiness()` immediately
69 readiness event.
76 // Await readiness
77 let event = self.readiness(interest).await?;
93 entry in the linked list includes the `interest` set passed to `readiness()`.
100 readiness: AtomicUsize,
118 // This struct is contained by the **future** returned by `readiness()`.
128 /// the value passed to `readiness()`
136 When an I/O event is received from `mio`, the associated resources' readiness is
138 overlap the received readiness event are notified. Any waiter with an `interest`
139 that does not overlap the readiness event remains in the list.
143 The future returned by `readiness()` uses an intrusive linked list to store the
144 waker with `ScheduledIo`. Because `readiness()` can be called concurrently, many
145 wakers may be stored simultaneously in the list. If the `readiness()` future is
158 // Await readiness
159 let event = self.readiness(interest).await?;
173 `clear_readiness(event)` is called, a readiness event arrives, the `read()`
174 function could deadlock. This happens because the readiness event is received,
175 `clear_readiness()` unsets the readiness event, and on the next iteration,
176 `readiness().await` will block forever as a new readiness event is not received.
182 Instead, we will use a strategy to prevent clearing readiness if an "unseen"
183 readiness event has been received. The I/O driver will maintain a "tick" value.
185 readiness event has an associated tick. When the I/O driver sets the resource's
186 readiness, the driver's tick is packed into the atomic `usize`.
188 The `ScheduledIo` readiness `AtomicUsize` is structured as:
198 The `readiness()` function returns a `ReadyEvent` value. This value includes the
199 `tick` component read with the resource's readiness value. When
202 If the tick values do not match, the call to `readiness()` on the next iteration
212 not possible to cancel interest in the readiness events.