Permalink
Reply
On Monday, 30 October 2023 at 16:20:00 UTC, Jonathan M Davis wrote:
>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
I just have very limited time to explain everything, but I can start.
Given the provided link
https://learn.microsoft.com/en-us/dotnet/api/system.threading.tasks.taskstatus?view=net-7.0
As you can see it contains TaskStatus.
| Canceled | 6 | The task acknowledged cancellation by throwing an OperationCanceledException with its own CancellationToken while the token was in signaled state, or the task's CancellationToken was already signaled before the task started executing. For more information, see Task Cancellation. | ||
|---|---|---|---|---|
| Created | 0 | The task has been initialized but has not yet been scheduled. | ||
| Faulted | 7 | The task completed due to an unhandled exception. | ||
| RanToCompletion | 5 | The task completed execution successfully. | ||
| Running | 3 | The task is running but has not yet completed. | ||
| WaitingForActivation | 1 | The task is waiting to be activated and scheduled internally by the .NET infrastructure. | ||
| WaitingForChildrenToComplete | 4 | The task has finished executing and is implicitly waiting for attached child tasks to complete. | ||
| WaitingToRun | 2 | The task has been scheduled for execution but has not yet begun executing. |
If we divide it in time, short term, middle term and long term changes.
A first change could for example be to expose the status as is, but as discussed earlier, it was not meant to be exposed from the beginning, but via alias this, it was just a mistake. I can understand that, and removing it makes sense.
A middle term change could be to implement a way to get a real status from a task in a correct way, whatever that would mean in D. The implemenation is not important.
A long term change would be a complete rewrite where basically a very detailed status could be probed from the task.
Imagine you have a super loop concept where you check the individual tasks. Now, what does checking a task mean?
In terms of what D could provide it would mean is it started, is it running or is it completed/done/failed/unknown. Much less than C#, but still something.
If you can only check if it's done, you don't know if it hasn't started yet or if it's running. The negation of "done" does not mean that it's running, it could also not be started.
I'm not talking about the current implementation in D. I am talking about a solution where you have a Task and you want to get the status from that task.
You will need to have to imagine a future object that can do this.
Of course I could try and rewrite Task, but it would probably take several weeks because I have barely looked at the code for it.
