4 ms·

> processes and forking are relatively expensive This and "async is always faster" are two things which are no longer true on modern hardware. Forking a proce

> processes and forking are relatively expensive This and "async is always faster" are two things which are no longer true on modern hardware. Forking a process on Linux uses the same clone() syscall as creating a thread so forking a small binary takes only tens of microseconds, leaving plenty of time for <1ms total response times. https://eli.thegreenplace.net/2018/launching-linux-threads-and-processes-with-clone/ https://eli.thegreenplace.net/2018/launching-linux-threads-a...

CraftThatBlock 8y ago
For sure, but the biggest overhead is usually application startup (in say Java, Dart, Node, Python, etc) where just the VM can take a few 100ms to start. Using a compiled language would most likely be the way to go for maximum performance (although it's less important if the WebSocket is long lasting)
jchw 8y ago
Sure. Under Linux, processes and threads are both just tasks anyways. Processes may be nearly as efficient as threads, but you can do one better by not even having to spawn new threads per worker, which is what a concurrency model like Go's or Erlang's enable with ease. CGI and Websocketd also have significantly more costs than just a fork since they need to execute a target program. And even forgetting the costs of forking, threads are not necessarily much better anyways. I can easily have a single Go program scheduling literally hundreds of thousands of Goroutines across just a few OS level threads and have no problems whatsoever, and in fact I've done exactly that in production, whereas I would never even dream of doing that with threads. Node.JS's event loop model also doesn't need to spawn threads per connections. When I say processes and forking are relatively expensive, I don't mean compared to doing the exact same thing with threads; I mean compared to more modern alternatives, like using an event loop or Goroutines.
- jashmatthews 8y ago
  I never wrote that going back to CGI and creating a process or thread per request was a good idea, only that forking is much cheaper than often thought. Event loops and userland cooperative multitasking like Goroutines predate Linux 2.6 kernel threads. They're not "more modern".
_pmf_ 8y ago
> Forking a process on Linux uses the same clone() syscall as creating a thread The conclusion to be drawn is "Linux threads are costly", not "Linux processes are cheap".
- inferiorhuman 8y ago
  Is it? I seem to remember that spawning a process on Linux was about as fast as a new thread on Windows XP.

CraftThatBlock 8y ago

For sure, but the biggest overhead is usually application startup (in say Java, Dart, Node, Python, etc) where just the VM can take a few 100ms to start. Using a compiled language would most likely be the way to go for maximum performance (although it's less important if the WebSocket is long lasting)

jchw 8y ago

Sure. Under Linux, processes and threads are both just tasks anyways. Processes may be nearly as efficient as threads, but you can do one better by not even having to spawn new threads per worker, which is what a concurrency model like Go's or Erlang's enable with ease. CGI and Websocketd also have significantly more costs than just a fork since they need to execute a target program. And even forgetting the costs of forking, threads are not necessarily much better anyways. I can easily have a single Go program scheduling literally hundreds of thousands of Goroutines across just a few OS level threads and have no problems whatsoever, and in fact I've done exactly that in production, whereas I would never even dream of doing that with threads. Node.JS's event loop model also doesn't need to spawn threads per connections. When I say processes and forking are relatively expensive, I don't mean compared to doing the exact same thing with threads; I mean compared to more modern alternatives, like using an event loop or Goroutines.

jashmatthews 8y ago
I never wrote that going back to CGI and creating a process or thread per request was a good idea, only that forking is much cheaper than often thought. Event loops and userland cooperative multitasking like Goroutines predate Linux 2.6 kernel threads. They're not "more modern".

_pmf_ 8y ago

> Forking a process on Linux uses the same clone() syscall as creating a thread The conclusion to be drawn is "Linux threads are costly", not "Linux processes are cheap".

inferiorhuman 8y ago
Is it? I seem to remember that spawning a process on Linux was about as fast as a new thread on Windows XP.