7 ms·

For servers that primarily speak RPC or HTTP, do you foresee Rust going thread-per-request or something more callback-y?

by agentS 11y ago

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.
pcwalton 11y ago
Most applications right now should do thread-per-request. Thread spawning is very optimized in both Rust and the Linux kernel, and you can adjust stack sizes if you need to. If you're hitting limits caused by this, you can use mio.
- Narishma 11y ago
  What about systems other than Linux?
  - pcwalton 11y ago
    Mac OS X is rarely used for servers, so I'm not particularly concerned about it. On Windows you can use user-mode scheduling—I would like to see a library for this—which is effectively 1:1.

For servers that primarily speak RPC or HTTP, do you foresee Rust going thread-per-request or something more callback-y?

by agentS 11y ago

For servers that primarily speak RPC or HTTP, do you foresee Rust going thread-per-request or something more callback-y?

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.

pcwalton 11y ago

Most applications right now should do thread-per-request. Thread spawning is very optimized in both Rust and the Linux kernel, and you can adjust stack sizes if you need to. If you're hitting limits caused by this, you can use mio.

Narishma 11y ago
What about systems other than Linux?
- pcwalton 11y ago
  Mac OS X is rarely used for servers, so I'm not particularly concerned about it. On Windows you can use user-mode scheduling—I would like to see a library for this—which is effectively 1:1.