Non-blocking I/O lets a thread continue useful work instead of waiting for an I/O operation to finish. It does not remove network or storage latency; it keeps that latency from idling the thread. section 9.2.4 section 10.2
Handling a web request
A server can start a database query, handle other events, and resume the request when the query completes. For a network connection, it can register interest in a socket becoming readable, process the arriving data, then wait for the socket to become writable before sending a response. One event-loop thread can thereby serve thousands of connections without assigning a waiting thread to each one. section 9.2.4 section 10.1.2
The event loop monitors event sources and dispatches ready work to handlers. Its wait for events may block when nothing is ready; a handler must not block, because that would stop the loop from serving other events. Handlers either finish promptly or defer work until a later event. Callbacks or futures can express dependencies between those steps. section 9.2.4 section 10.1.2
struct EventLoop {
// Holds registered event sources like sockets, files, timers
sources: Vec<EventSource>,
}
impl EventLoop {
fn run(&mut self) {
loop {
// Create a new collection to store events
let mut events = Events::new();
// Poll for new events with a timeout
self.poll(&mut events, Duration::from_millis(100));
// Process each event that was found
for event in events.iter() {
self.process_event(&event);
}
// Run any scheduled tasks
self.run_scheduled_tasks();
}
}
}
The loop polls registered sources, processes ready events, then runs scheduled tasks. This is the infrastructure that lets work proceed while individual I/O operations wait. section 10.1.2
