Threads and Polling

The crate starts no threads and needs no async runtime: every callback runs on a thread the application lent to a polling call.

• A route handler runs on the thread inside take_call or take_calls for the event loop that received the request.
• A batch handler runs on the thread inside take_batch or take_batches for its endpoint, never on an event loop.
• A server’s peer authorizer runs on the polling thread completing the handshake, and a client’s on the client’s own thread inside take_completed, call, get or post.

Each event loop and each batch endpoint has one polling owner at a time, and a second thread polling it concurrently gets Status::Contended. take_calls and take_batches run until Server::stop, while take_call and take_batch return after one round, waiting up to their timeout, so a loop of them interleaves polling with other work on the same thread. Server::stop works from any thread, handlers included, wakes every polling thread, and dropping the Server stops it too. The first stop drains, answering every request already held before its connection closes, and a second one cuts the replies still in flight. An interface accepts on its own number of event loops, one by default, and the server runs the largest of those counts.

Registration takes &mut Server, and polling, stopping and statistics take &Server, so the borrow checker orders setup before serving. A Request and a Response move between threads, while a Client stays on the thread that created it. Every thread that polls, replies or reads must run on a CPU supporting the CPU class the server or client resolved at start, so CPUClass::Serial is the safe choice on machines mixing CPU generations.