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.

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

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).

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.

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.

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.

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.