3 ms·

Easy to implement.

nine_k 3y ago
But does anyone run an OS thread per request unironically? I thought that nearly every request-response server implementation would use a thread pool. The best, like Erlang, can give you the feeling of arbitrarily many extremely cheap threads, while also running on a thread pool.
- marginalia_nu 3y ago
  As a devil's advocate argument, if you're doing serverside rendering, and basically getting 1 request per visit, sure there's overhead, but even like a landslide HN death hug is only a handful requests per second. A raspberry pi could feasibly serve that traffic spawning 1 thread per request. ... not that I think anyone is doing this outside of maybe some hobbyist building their own HTTP server for fun.
- gmfawcett 3y ago
  > does anyone run an OS thread per request unironically? Of course they do. There are loads of appropriate applications. Heck, people still run CGI programs unironically.
  - sgift 3y ago
    And if your use case allows it it is a great model. Easy to setup, easy to debug, easy to run. Also, why I love the new virtual threads in Java. Will they work as good as hoped? No idea. Probably not for all use cases. But the direction to say: You know what, threads are great to program and debug compared to the alternatives, maybe let's find a way to make their performance better instead of putting up with async , is so refreshing.
- yencabulator 3y ago
  As far as comparisons to thread-per-core go, thread per request applies whether it's an OS thread or a green thread or a Rust async function compiled into a state machine. Anything that multiplexes per-request contexts into a lesser amount of cores(/OS threads) has the same trade-offs, the difference is more on the easy-vs-optimized spectrum. Thread-per-core with fixed workloads behaves differently than all of those. Here's an example difference: in thread-per-request, any global state can be accessed from "anywhere", and thus you end up with locks, reference counts, GC, and what not. In thread-per-core, global state is sharded across cores and never accessed "from the outside", and thus needs no locks/atomics (beyond the messaging primitive).
  - gmfawcett 3y ago
    > In thread-per-core, global state is sharded across cores and never accessed "from the outside" ...or possibly it's accessed from everywhere, and locks are needed again. What you're describing is kind of an ideal application architecture, not a hard rule about thread pinning.
    - nine_k 3y ago
      What you need to share, you may adorn with locks, queues, etc. But ideally you share very little. "Possibly accessed from anywhere" is a bad design in general, and unacceptable in realtime processing, where you need to know access patterns exactly.

Easy to implement.

But does anyone run an OS thread per request unironically? I thought that nearly every request-response server implementation would use a thread pool. The best, like Erlang, can give you the feeling of arbitrarily many extremely cheap threads, while also running on a thread pool.

marginalia_nu 3y ago
As a devil's advocate argument, if you're doing serverside rendering, and basically getting 1 request per visit, sure there's overhead, but even like a landslide HN death hug is only a handful requests per second. A raspberry pi could feasibly serve that traffic spawning 1 thread per request. ... not that I think anyone is doing this outside of maybe some hobbyist building their own HTTP server for fun.
gmfawcett 3y ago
> does anyone run an OS thread per request unironically? Of course they do. There are loads of appropriate applications. Heck, people still run CGI programs unironically.
- sgift 3y ago
  And if your use case allows it it is a great model. Easy to setup, easy to debug, easy to run. Also, why I love the new virtual threads in Java. Will they work as good as hoped? No idea. Probably not for all use cases. But the direction to say: You know what, threads are great to program and debug compared to the alternatives, maybe let's find a way to make their performance better instead of putting up with async , is so refreshing.
yencabulator 3y ago
As far as comparisons to thread-per-core go, thread per request applies whether it's an OS thread or a green thread or a Rust async function compiled into a state machine. Anything that multiplexes per-request contexts into a lesser amount of cores(/OS threads) has the same trade-offs, the difference is more on the easy-vs-optimized spectrum. Thread-per-core with fixed workloads behaves differently than all of those. Here's an example difference: in thread-per-request, any global state can be accessed from "anywhere", and thus you end up with locks, reference counts, GC, and what not. In thread-per-core, global state is sharded across cores and never accessed "from the outside", and thus needs no locks/atomics (beyond the messaging primitive).
- gmfawcett 3y ago
  > In thread-per-core, global state is sharded across cores and never accessed "from the outside" ...or possibly it's accessed from everywhere, and locks are needed again. What you're describing is kind of an ideal application architecture, not a hard rule about thread pinning.
  - nine_k 3y ago
    What you need to share, you may adorn with locks, queues, etc. But ideally you share very little. "Possibly accessed from anywhere" is a bad design in general, and unacceptable in realtime processing, where you need to know access patterns exactly.