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