| |
![Jonathan M Davis's Gravatar profile Gravatar of Jonathan M Davis](//www.gravatar.com/avatar/c2372c89dbe85590c9c1dd06c6f998e0?d=identicon&s=32) | Posted by Jonathan M Davis in reply to Sergey | Permalink Reply |
|
Jonathan M Davis ![Jonathan M Davis's Gravatar profile Gravatar of Jonathan M Davis](//www.gravatar.com/avatar/c2372c89dbe85590c9c1dd06c6f998e0?d=identicon&s=80)
Posted in reply to Sergey
| On Monday, October 30, 2023 1:48:46 AM MDT Sergey via Digitalmars-d wrote:
> On Sunday, 29 October 2023 at 21:32:18 UTC, Jonathan M Davis
>
> wrote:
> > 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
>
> Hi Jonathan.
> The author of the topic came to D from C#. And in the C# they
> have this feature. On of the example is to check the status of
> the tasks - if it was successfully finished, canceled, killed by
> exception.
> Some simple example can be found here:
> https://learn.microsoft.com/en-us/dotnet/api/system.threading.tasks.taskstat
> us?view=net-7.0
Thanks for the info.
Task in std.parallelism already provides the done property to ask whether a task has been completed (be it successfully or by an exception being thrown). It does not provide any way to cancel tasks, and the functions on Task which deal with actually making it do anything are largely variations on getting the result (be it by getting it because it's already ready, by waiting for it to be completed, or by actually forcing the task to be done on the current thread to get the result). As such, there does not appear to be anything useful which can be done based on the task status except based on whether it's done or not - which Task already provides.
So, with the API that std.parallelism provides, actually making the TaskStatus public does not appear to have any useful purpose, and by its very nature, the answer stands a decent chance of being out-of-date, because once the TaskStatus is outside of the Task, it's just information on what the status was when it was synchronized from the thread that it was on, not information on what the actual, current status is. So, acting on that information risks introducing race conditions (assuming that you can actually do anything with that information), and if you can't actually do anything with that information (and std.parallelism doesn't seem to make it so that you can), then there's no point in exposing it.
It might make sense to expose the TaskStatus with a different API (which C# obviously has if it's going to allow things like canceling tasks), but no one has provided a good reason for why it should be exposed in std.parallelism beyond the done property which already exists. And sadly, Imperatorn has repeatedly decided to get mad with us rather than engage in a technical discussion on why exposing the task's status beyond having the done property would actually be a good idea. It's quite possible that there is something that we are missing, and exposing the TaskStatus actually makes sense, but there need to be technical reasons for that, and none have been presented.
- Jonathan M Davis
|