Thread overview
[Issue 21232] std.parallelism.parallel reuses thread, leading to stale static data
Sep 09, 2020
kinke
Sep 10, 2020
Mathias LANG
Sep 10, 2020
Bruce Carneal
September 09, 2020
https://issues.dlang.org/show_bug.cgi?id=21232

kinke <kinke@gmx.net> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |kinke@gmx.net

--- Comment #1 from kinke <kinke@gmx.net> ---
Pardon me, but isn't this to be expected? Creating a thread per iteration would be an absolutely inacceptable overhead in many cases. From the std.parallelism docs:

"After creation, a Task may be executed in a new thread, or submitted to a TaskPool for execution. A TaskPool encapsulates a task queue and its worker threads. Its purpose is to efficiently map a large number of Tasks onto a smaller number of threads."

--
September 10, 2020
https://issues.dlang.org/show_bug.cgi?id=21232

--- Comment #2 from Mathias LANG <pro.mathias.lang@gmail.com> ---
> Pardon me, but isn't this to be expected? Creating a thread per iteration would be an absolutely inacceptable overhead in many cases.

It might be unacceptable performance-wise, but I think violating the type-system like this is even less acceptable. `std.parallelism` (and `std.concurrency`) do that on multiple occasions, by not requiring a `shared` delegate and executing things in threads "sometimes".

D2 was designed to have a strong distinction between data that is used by multiple threads and data that isn't, with the assumption that the latter is the most common case. `parallel` is just trampling all over this.

--
September 10, 2020
https://issues.dlang.org/show_bug.cgi?id=21232

Bruce Carneal <bcarneal11@gmail.com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |bcarneal11@gmail.com

--- Comment #3 from Bruce Carneal <bcarneal11@gmail.com> ---
Having library choices for both speed (task pools) and fidelity (heavy weight spawn) seems like a good thing.  Anecdotally I've used both and had problems with neither but then I never expected full thread semantics from the task pool.

--
December 01
https://issues.dlang.org/show_bug.cgi?id=21232

--- Comment #4 from dlangBugzillaToGithub <robert.schadek@posteo.de> ---
THIS ISSUE HAS BEEN MOVED TO GITHUB

https://github.com/dlang/phobos/issues/9806

DO NOT COMMENT HERE ANYMORE, NOBODY WILL SEE IT, THIS ISSUE HAS BEEN MOVED TO GITHUB

--