This example is not very useful

[Seabizkit]

The reason

it is point less to have to wait for all task to be completed for the main task to be marked as cancelled.

example: why would you want this

// Task 1 executing
// Task 2 executing
// Task 3 executing
// Task 4 executing
// Task 5 executing
// Task 6 executing
// Task 7 executing
// Task 8 executing
// c
// Task cancellation requested.
// Task 2 cancelled
// Task 7 cancelled
//
// OperationCanceledException thrown

example: This is what you would want

// Task 1 executing
// Task 2 executing
// Task 3 executing
// Task 4 executing
// Task 5 executing

// Task 6 executing
// Task 7 executing

// c
// Task cancellation requested.
// Task 2 cancelled
// OperationCanceledException thrown
// Task 7 cancelled
// Task 8 cancelled

you dont want to have to wait for all to be cancelled before being allowed to cancel...

if you had 100 tasks and you are controlling the execution,
lets say its completed 40
then if it hasn't started x (60) tasks why would you want to wait for say
another x cancels to be processed before saying it cancelled.

another thing is DoSomeWork is not async, which in most modern use cases it would be aka
say the tasks were to download a file and then have retry logic ect. this would most like be async in side the DoSomeWork method.

---

Document Details

⚠ Do not edit this section. It is required for docs.microsoft.com ➟ GitHub issue linking.

• ID: d994a93a-8eb5-9de3-d18f-121d8d63312f
• Version Independent ID: 8d25baef-270a-2af8-c96e-2bbc9da49640
• Content: How to: Cancel a Task and Its Children
• Content Source: docs/standard/parallel-programming/how-to-cancel-a-task-and-its-children.md
• Product: dotnet-fundamentals
• GitHub Login: @IEvangelist
• Microsoft Alias: dapine

[IEvangelist]

Hi @Seabizkit - I'd be happy for you to update the example source code and corresponding article. Feel free to tag me on the PR and I'll review it. Is that something you'd be interested in doing?

[Seabizkit]

@IEvangelist Hi, the example perfectly shows how to wait until all are cancelled.. but say you were downloading 1000 files..., let say that only 200 have started or doenst really mattter the amount, more importantly the threads haven't even started..., it would be like waiting for x downloads to fail. example well from what i understand is it wont kick off 1000 at once it will be used from the thread pool, but in this example we have to wait for each 1000 to start and then fail... for it to be done. it would be a nicer example if we could issue a cancel and then it cancels even the start of the onces it hasnt started so it could exit sooner. in this example there would be a long delay between the issue of the cancel and when it actually come back. Example start work, then 2 seconds later cancel. it would still have to start like 800 and then determine they actually going to throw cancels. u minght end up waiting +- 1 second for each 1, so like 1min for it to come back and say its cancelled. Hope that made sense

[Seabizkit]

aka maybe something like

await Task.WhenAny(allChildernTasks, cancellationTask);

that way u could cancel like straight away and the rest of the work willl happen in the background, including the making of each task as cancelled

[IEvangelist]

Using the WhenAny will finish as soon as the first task completes, which is not ideal. That means that you'd have many other tasks still starting and running, and that wouldn't even catch cancellation as it would have already continued on.

[Seabizkit]

@IEvangelist Hi, I think what was important was the naming

await Task.WhenAny(allChildernTasks, cancellationTask);

where .... the first 1 is a Task which wraps all children tasks, aka its only considered done, when all are done.

So now if either all are done or its cancels it will break out as soon as that is done, which is a lot sooner... than

having to wait for all tasks to be started and then canceled.

There are other ways of handing this but I'm simply saying that the flow

start.. 1000 tasks, then cancelling and having to wait for all 1000 to be started and then cancelled could be a wait time of x secs or minutes, where the expected usage would be i click cancel and then less than 5 secs later it should say done cancelled, instead of waiting greater than 5++ secs(maybe minutes) to say cancelled.

Hope that makes sense.

[IEvangelist]

@Seabizkit Ah, I see. Yes, that does make a lot more sense now. Would you like to create a PR to adjust this code?