Hacker News Reader

Comment by dunkelheit | Hacker News Reader

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.

View on HN

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.

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.

> 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.)

> 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?

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.

Reply on news.ycombinator.com