www.digitalmars.com         C & C++   DMDScript  

digitalmars.D.learn - Thread pools

reply "Chris" <wendlec tcd.ie> writes:
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.
Jul 22 2015
parent reply "Alex Parrill" <initrd.gz gmail.com> writes:
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
Jul 22 2015
parent reply "Chris" <wendlec tcd.ie> writes:
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).
Jul 22 2015
parent reply "John Colvin" <john.loughran.colvin gmail.com> writes:
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.
Jul 22 2015
next sibling parent reply "Marc =?UTF-8?B?U2Now7x0eiI=?= <schuetzm gmx.net> writes:
On Wednesday, 22 July 2015 at 16:16:36 UTC, John Colvin wrote:
 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:
 [...]
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.
You can probably simply terminate the main thread, which will send an OwnerTerminated message to all dependent threads. The threads need to `receive()` this message and terminate.
Jul 22 2015
parent "Chris" <wendlec tcd.ie> writes:
On Wednesday, 22 July 2015 at 17:01:52 UTC, Marc Sch├╝tz wrote:
 You can probably simply terminate the main thread, which will 
 send an OwnerTerminated message to all dependent threads. The 
 threads need to `receive()` this message and terminate.
Not possible here. Main has to run the all the time, it's waiting for input and spawns threads accordingly.
Jul 23 2015
prev sibling parent "Chris" <wendlec tcd.ie> writes:
On Wednesday, 22 July 2015 at 16:16:36 UTC, John Colvin wrote:

 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.
Thanks. I was thinking the same when I gave it a second thought on my way home. Instead of having a central pool, every thread is responsible for its own threads. So main only needs to care about the initial thread. That's the theory, I'll have to see how this works in reality.
Jul 23 2015