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?
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?





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?





 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