3 ms·

Does that mean that one can use system threads as frivolously as goroutines (e.g. spawning new thread for each incoming request)? Conventional C++ wisdom advice

Does that mean that one can use system threads as frivolously as goroutines (e.g. spawning new thread for each incoming request)? Conventional C++ wisdom advices against it. But then it may be informed by some old and bad pthreads implementations.

jhartmann 11y ago
A reasonable compromise is to use a threadpool (which is a big part of what comes with wangle) with a fixed number of threads and you queue the tasks to be run by the threads. It works quite well in practice, and you can use coroutines (I'm most familiar with the implementation in boost coroutine and the Ewan webserver personally) to go the whole hog and get something as lightweight as Erlang green threads or goroutines. I would only bother doing that of course if in your particular use case you find the threadpool doesn't perform well. With proper sizing and broken up units of work, it really works quite well in practice.
pcwalton 11y ago
Usually memory usage ends up being the limiting factor, not thread spawning performance. Memory usage is independent of 1:1 vs. M:N, though, as pthread stack sizes are configurable.
otabdeveloper 11y ago
> Does that mean that one can use system threads as frivolously as goroutines (e.g. spawning new thread for each incoming request)? Yes. In fact, under Linux oftentimes spawning a thread and then running a system call can be faster than just running a system call. > Conventional C++ wisdom advices against it. With 32 bit CPU's you might run out of virtual memory quickly, since each thread allocates virtual memory for its stack. With 64 bit CPU's there are no issues. (Also never forget that virtual memory isn't real memory, it's just a page counter.)
- pcwalton 11y ago
  > Yes. In fact, under Linux oftentimes spawning a thread and then running a system call can be faster than just running a system call. Interesting, do you have any further info (references, cites) on this?
  - scott_s 11y ago
    Sign me up for wanting more info as well. I'm curious how that could work out, since spawning a thread is a system call.

jhartmann 11y ago

A reasonable compromise is to use a threadpool (which is a big part of what comes with wangle) with a fixed number of threads and you queue the tasks to be run by the threads. It works quite well in practice, and you can use coroutines (I'm most familiar with the implementation in boost coroutine and the Ewan webserver personally) to go the whole hog and get something as lightweight as Erlang green threads or goroutines. I would only bother doing that of course if in your particular use case you find the threadpool doesn't perform well. With proper sizing and broken up units of work, it really works quite well in practice.

pcwalton 11y ago

Usually memory usage ends up being the limiting factor, not thread spawning performance. Memory usage is independent of 1:1 vs. M:N, though, as pthread stack sizes are configurable.

otabdeveloper 11y ago

> Does that mean that one can use system threads as frivolously as goroutines (e.g. spawning new thread for each incoming request)? Yes. In fact, under Linux oftentimes spawning a thread and then running a system call can be faster than just running a system call. > Conventional C++ wisdom advices against it. With 32 bit CPU's you might run out of virtual memory quickly, since each thread allocates virtual memory for its stack. With 64 bit CPU's there are no issues. (Also never forget that virtual memory isn't real memory, it's just a page counter.)

pcwalton 11y ago
> Yes. In fact, under Linux oftentimes spawning a thread and then running a system call can be faster than just running a system call. Interesting, do you have any further info (references, cites) on this?
- scott_s 11y ago
  Sign me up for wanting more info as well. I'm curious how that could work out, since spawning a thread is a system call.