reddit discussion about Go turns to D again

[dsimcha]

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.