Future of D

Mon Oct 30 19:23:58 UTC 2023

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.