On Friday, 17 June 2016 at 14:29:57 UTC, Russel Winder wrote:
A priori, assuming I am not missing anything, this behaviour
seems entirely reasonable.
I agree that when using non-daemon threads (and I personally
think that should be the default) that it is. But I cannot bring
that into accord with the documentation of taskPool (the
property)[1]:
Returns a lazily initialized global instantiation of TaskPool.
[...]
The worker threads in this pool are daemon threads, meaning
that it is not necessary to call TaskPool.stop or
TaskPool.finish before terminating the main thread.
A daemon thread is automatically terminated when all non-daemon
threads have terminated.
A non-daemon thread will prevent a program from terminating as
long as it has not terminated.
The above - while not explicitly stating that daemon-threads do
not prevent a program from terminating - are - to me - strongly
suggesting it (and if they do indeed not, then I would ask how
daemon threads are differnt from non-daemon threads in the
context of TaskPool, since I'm unable to make it out from the
documentation).
The task is an infinite loop so it never terminates. This means
the threadpool does not stop working, which means the program
does not terminate.
Yes, that example is intentionally chosen that way to make my
point. I initially discovered this while putting of a synchronous
read of STDIN in a loop, but that example might have diverted
attention to something other than I intended.
I suspect that daemon may not mean what you think it means. At
least not with respect to the threadpool.
I do, too, which is why I asked here, since after having read the
relevant documentation several times with significant time delay
in between I still cannot make out how else to interpret it (and
I got no reply in #dlang IRC).
[1] https://dlang.org/library/std/parallelism/task_pool.html
