4 ms·
Neither. Existing successful solutions use tight event loops (the "Reactor pattern": https://stackoverflow.com/questions/3436808/how-does-nginx-handle-http-requ
by eddyb 11y ago
Neither. Existing successful solutions use tight event loops (the "Reactor pattern": https://stackoverflow.com/questions/3436808/how-does-nginx-handle-http-requests https://stackoverflow.com/questions/3436808/how-does-nginx-h...).
There is a Rust library called "mio" which provides a lot of the plumbing for such systems: https://github.com/carllerche/mio https://github.com/carllerche/mio.
The path forward is likely going to involve adding a way to build cheap state machines (call them generators or async/await) with a clean syntax and giving mio hundreds of thousands of reusable instances.
- agentS 11y ago> ... Reactor pattern ... I don't understand, and the link seems unclear. Perhaps a more direct question: I get a request X, and I need to consult a backend service to answer the request. Do I write synchronous code calling that backend? Or do I have some callback mechanism? > ... generators or async/await Ah. This perhaps answers my question. Both of these are essentially compiler-written callbacks. If this is going to be like C#, then I presume there will be a thread-pool where user code will execute. It seems like a non-ideal story for concurrency. Users will have to take inordinate care not to call any blocking code; otherwise they will prevent one of the threads in the pool from doing useful work.
- pcwalton 11y ago> It seems like a non-ideal story for concurrency. Users will have to take inordinate care not to call any blocking code; otherwise they will prevent one of the threads in the pool from doing useful work. The downsides of going M:N are worse. The cgo-like FFI performance problems, for example, are killer for Rust's use case.