|
|
|
|
|
|
by jayd16
1373 days ago
|
|
|
As far as defining scope goes, C# gets away with unchecked exceptions. Exceptions just bubble up naturally. Task scope is more implicit in syntax but scheduling Context is used in a similar way to scopes. The difference is context is usually inferred instead of explicitly defined at every use. |
|
|
If 4 tasks are started asynchronously and one of them throws? What do you want to happen to the other 3?
In structured concurency you could say, if any of them fails then cancel all others, and retry them all.
Or for example, if one task is waiting on another and that first task throws an exception, you might want to say, ok, retry the first and re-schedule the other one to wait on that retried task.
These are all things you can handle yourself as well, but structured concurency is just trying to make that less effort and automatic. So if you define a supervision scope, everything inside it no matter how complex the async graph is, it'll all cancel/retry appropriately at that scope.
The scope will also guarantee that when we leave the scope, all concurent tasks are done, nothing is left running, either because it's all cancelled or the scope waits for all tasks to complete.
Here's some good articles that explains the motivation for it:
https://elizarov.medium.com/structured-concurrency-722d765aa...
https://github.com/apple/swift-evolution/blob/main/proposals...