On Monday, 4 August 2014 at 14:56:36 UTC, Philippe Sigaud via
Digitalmars-d-learn wrote:
On Mon, Aug 4, 2014 at 3:36 PM, Dicebot via Digitalmars-d-learn
<digitalmars-d-learn@puremagic.com> wrote:
Most likely those threads either do nothing or are short
living so you don't
get actually 10 000 threads running simultaneously. In general
you should
expect your operating system to start stalling at few
thousands of
concurrent threads competing for context switches and system
resources.
Creating new thread is rather costly operation though you may
not spot it in
synthetic snippets, only under actual load.
Modern default approach is to have amount of "worker" threads
identical or
close to amount of CPU cores and handle internal scheduling
manually via
fibers or some similar solution.
That's what I guessed. It's juste that I have task that will
generate
other (linked) tasks, in a DAG. I can use a thread pool of 2-8
threads, but that means storing tasks and their relationships
(which
is waiting on which, etc). I rather liked the idea of spawning
new
threads when I needed them ;)
vibe.d additions may help here:
http://vibed.org/api/vibe.core.core/runTask
http://vibed.org/api/vibe.core.core/runWorkerTask
http://vibed.org/api/vibe.core.core/workerThreadCount
"task" abstraction allows exactly that - spawning new execution
context and have it scheduled automatically via underlying
fiber/thread pool. However, I am not aware of any good tutorials
about using those so jump in at your own risk.
If you are totally new to the topic of concurrent services,
getting familiar
with http://en.wikipedia.org/wiki/C10k_problem may be useful :)
I'll have a look. I'm quite new, my only knowledge comes from
reading
the concurrency threads here, std.concurrency, std.parallelism
and
TDPL :)
Have fun :P It is rapidly changing topic though, best practices
may be out of date by the time you have read them :)
