5 ms·

As far as I know Golang uses the thread-per-connection model. Furthermore, in languages such as Erlang having an actor-based model, there are thousands and tho

As far as I know Golang uses the thread-per-connection model. Furthermore, in languages such as Erlang having an actor-based model, there are thousands and thousands of microthreads. I think if you use lightweight threads (green threads, goroutines, etc.), the model does scale.

xxs 9y ago
>>I think if you use lightweight threads (green threads, goroutines, etc.), the model does scale. That's no thread - unless there is a real context switch (and cold caches) to pay for.
sudhirj 9y ago
Lightweight threads don't count as real threads - that's a different concurrency model that may or may not map to actual OS threads. In Go, for example, I don't think OS threads are used at all, just processes. You can set GO_MAX_PROCS=1, for instance, and have all your goroutines running on a single process, effectively making it a single threaded system like Node. In that scenario, you're back at cooperative scheduling, because control will only transfer to another goroutine if you delegate to a runtime call or call os.Gosched() which is an explicit sleep + control transfer.
- sudhirj 9y ago
  This is actually a viable deployment strategy for Go programs, with a few people recommending it. The advantage is that your code cannot possibly have race conditions, even as it works with any number of goroutines. To better utilize multicore hardware, you'd use something like https://github.com/stripe/einhorn https://github.com/stripe/einhorn to share the incoming socket with as many Go processes as you have processor cores. Since Go's memory footprint is so low, this is actually a pretty decent way to do things.
sudhirj 9y ago
The better example would be Ruby + Puma. If you tell puma to set WORKERS=4 and MAX_THREADS=10, for example, you'll run 4 processes with 10 threads on each, giving you an explicit 40 simultaneous requests on that machine. No more under any circumstances.

xxs 9y ago

>>I think if you use lightweight threads (green threads, goroutines, etc.), the model does scale. That's no thread - unless there is a real context switch (and cold caches) to pay for.

sudhirj 9y ago

Lightweight threads don't count as real threads - that's a different concurrency model that may or may not map to actual OS threads. In Go, for example, I don't think OS threads are used at all, just processes. You can set GO_MAX_PROCS=1, for instance, and have all your goroutines running on a single process, effectively making it a single threaded system like Node. In that scenario, you're back at cooperative scheduling, because control will only transfer to another goroutine if you delegate to a runtime call or call os.Gosched() which is an explicit sleep + control transfer.

sudhirj 9y ago
This is actually a viable deployment strategy for Go programs, with a few people recommending it. The advantage is that your code cannot possibly have race conditions, even as it works with any number of goroutines. To better utilize multicore hardware, you'd use something like https://github.com/stripe/einhorn https://github.com/stripe/einhorn to share the incoming socket with as many Go processes as you have processor cores. Since Go's memory footprint is so low, this is actually a pretty decent way to do things.

sudhirj 9y ago

The better example would be Ruby + Puma. If you tell puma to set WORKERS=4 and MAX_THREADS=10, for example, you'll run 4 processes with 10 threads on each, giving you an explicit 40 simultaneous requests on that machine. No more under any circumstances.