On 5/15/2011 1:38 PM, Sean Cavanaugh wrote:
On 5/15/2011 11:49 AM, dsimcha wrote:
On 5/15/2011 12:21 PM, Sean Cavanaugh wrote:
I haven't looked at the library in depth, but after taking a peek I'm
left wondering how to configure the stack size. My concern is what to do
if the parallel tasks are running out of stack, or (more likely) are
given way too much stack because they need to 'handle anything'.
I never thought to make this configurable because I've personally never
needed to configure it. You mean the stack sizes of the worker threads?
I just use whatever the default in core.thread is. This probably errs on
the side of too big, but usually you're only going to have as many
worker threads as you have cores, so it's not much waste in practice.
If you really need this to be configurable, I'll add it for the next
release.
I'm used to working with embedded environments so its just something I
notice right away when looking at threaded libraries. We generally have
to tune all the stacks to the bare minimum to get memory back, since its
extremely noticeable when running on a system without virtual memory. A
surprising number of tasks can be made run safely on 1 or 2 pages of stack.
Looking into core.thread the default behavior (at least on windows) is
to use the same size as the main thread's stack, so basically whatever
is linked in as the startup stack is used. It is a safe default as
threads can handle anything the main thread can and vice versa, but is
usually pretty wasteful for real-world work tasks.
A single thread pool by itself is never really the problem. Pretty much
each set of middleware that does threading makes their own threads and
thread pools, and it can and up pretty fast. Even a relatively simple
application can end up with something like 20 to 50 threads, if any of
the libraries are threaded (audio, physics, networking, background io etc).
Anyway, if you have lots of threads for various reasons, you can quickly
have 50-100MB or more of your address space eaten up with stack. If this
happens to you say, on an XBOX 360, thats 10-20% of the RAM on the
system, and tuning the stacks is definitely not a waste of time, but it
has to be possible to do it :)
Fair enough. So I guess stackSize should just be a c'tor parameter and
there should be a global for the default pool, kind of like
defaultPoolThreads? Task.executeInNewThread() would also take a stack
size. Definitely do-able, but I'm leery of cluttering the API with a
feature that's probably going to be used so infrequently.
