Thread pools

John Colvin via Digitalmars-d-learn digitalmars-d-learn at puremagic.com
Wed Jul 22 09:16:33 PDT 2015


On Wednesday, 22 July 2015 at 15:51:23 UTC, Chris wrote:
> On Wednesday, 22 July 2015 at 15:41:06 UTC, Alex Parrill wrote:
>> On Wednesday, 22 July 2015 at 14:28:48 UTC, Chris wrote:
>>> What would be the best way to manage different threads 
>>> (spawned via std.concurrency), e.g. to tell them to stop at 
>>> once, once a new command comes in? A thread pool? How would 
>>> that look like in D? I feel my knowledge of D threads is 
>>> still a bit limited.
>>
>> `std.parallelism` includes a TaskPool class [1] and a taskPool 
>> property [2], but they spawn their own threads.
>>
>> I'm not sure why you need a thread pool to tell 
>> std.concurrency threads to stop; why not send a stop message 
>> to each of them?
>>
>> [1]: http://dlang.org/phobos/std_parallelism.html#.TaskPool
>> [2]: http://dlang.org/phobos/std_parallelism.html#.taskPool
>
> Thanks. I'm dealing with "nested" threads at the moment.
>
> main
> {
>   spawn(thread1)
>   {
>     // Does some processing
>     spawn(thread2)
>     {
>       // Plays audio
>     }
>   }
> }
>
> If main receives a signal, all threads should stop immediately 
> (thread1 and thread2).

I would send a message to terminate to thread1, which would in 
turn send a similar message to any threads it has started, wait 
until they've all stopped (maybe with a time-out), then return.

I.e. every thread knows how to cleanly terminate itself when 
instructed, so you just send a terminate message down the tree of 
threads and then wait for the effects to bubble back up to main.


More information about the Digitalmars-d-learn mailing list