Future of D

[Jonathan M Davis]

On Sunday, October 29, 2023 3:03:00 PM MDT Imperatorn via Digitalmars-d wrote:
> On Sunday, 29 October 2023 at 20:39:19 UTC, Walter Bright wrote:
> > On 10/29/2023 11:38 AM, Imperatorn wrote:
> >> A bug report has been created for it by schveiguy since I
> >> can't access bugzilla because of an intermittent DNS problem.
> >
> > And a PR:
> >
> > https://github.com/dlang/phobos/pull/8834
> >
> >> Next step is to provide a safe way to get the task status
> >> after the pr has been merged.
>
> Yes, it's great to see. Now the next step is to improve it so
> that you can get the task status safely 😎

You have yet to explain why that information should be made public. Even if
you can get the task status without breaking thread-safety, the information
is still likely to be out-of-date by the time you actually try to do
anything based on it, because once you have the state information out of the
Task, that state information is no longer synchronized across threads. It's
just a copy of what the state was when the state was copied across threads.
So, actually making it possible to get the state information in a
thread-safe manner doesn't fix the problem that trying to do anything based
on that information involves race conditions.

And none of the functions on the Task are designed in such a way that it
really makes sense to call them or not based on whether a task has started
or not. The design of std.parallelism very purposefully only exposed the
status of whether the task is done or not, because that's really the only
actionable state information with the set of functions that it provides.

In general, trying to do anything based on whether the task has started or
not is going to be subject to race conditions unless what you're trying to
do is actually built into the Task like the *Force functions are.

So, the question is what problem are you trying to solve by making the task
status public? What does that enable that you cannot currently do without
that information?

If you have a good use case, then it may make sense to expose the state
information, but as was pointed out in your previous PR, exposing that state
information is likely to mislead programmers and risk causing them to write
code that has race conditions due to out-of-date state information - and no
one reviewing the PR saw how exposing that state information would actually
enable anything. So, please provide a use case where exposing that state
information actually enables something that you can't do without it.

- Jonathan M Davis