Design and introduction to epoll 71 Registry implements one important method we won't implement in our example, called try_clone. The reason we won't implement this is that we don't need it to understand how an event loop like this works and we want to keep the example simple and easy to understand. However, this method is important for understanding why the responsibility of registering events and the queue itself is divided. Important note By moving the concern of registering interests to a separate struct like this, users can call Registry::try_clone to get an owned Registry instance. This instance can be passed to, or shared through Arc<Registry> with, other threads, allowing multiple threads to register interest to the same Poll instance even when Poll is blocking another thread while waiting for new events to happen in Poll::poll. Poll::poll requires exclusive access since it takes a &mut self, so when we're waiting for events in Poll::poll, there is no way to register interest from a different thread at the same time if we rely on using Poll to register interest, since that will be prevented by Rust's type system. It also makes it effectively impossible to have multiple threads waiting for events by calling Poll::poll on the same instance in any meaningful way since it would require synchronization that essentially would make each call sequential anyway. The design lets users interact with the queue from potentially many threads by registering interest, while one thread makes the blocking call and handles the notifications from the operating system. Note The fact that mio doesn't enable you to have multiple threads that are blocked on the same call to Poll::poll isn't a limitation due to epoll, kqueue, or IOCP. They all allow for the scenario that many threads will call Poll::poll on the same instance and get notifications on events in the queue. epoll even allows specific flags to dictate whether the operating system should wake up only one or all threads that wait for notification (specifically the EPOLLEXCLUSIVE flag). The problem is partly about how the different platforms decide which threads to wake when there are many of them waiting for events on the same queue, and partly about the fact that there doesn't seem to be a huge interest in that functionality. For example, epoll will, by default, wake all threads that block on Poll, while Windows, by default, will only wake up one thread. Y ou can modify this behavior to some extent, and there have been ideas on implementing a try_clone method on Poll as well in the future. For now, the design is like we outlined, and we will stick to that in our example as well. This brings us to another topic we should cover before we start implementing our example.