reddit discussion about Go turns to D again

[Sean Cavanaugh]

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



As an unrelated note I got the magic VC exception that names threads in 
the visual studio debugger to work in D pretty easily, if anyone wants 
it I've linked it :)

http://snipt.org/xHok