I was previously undecided on whether it should be done implicitly, but it has turned out to be surprising, so, now I'm convinced that the right thing to do is to forbid cancelation propagation during resource release calls.
The issue is that if a fiber gets canceled, then resource release operations that might need to await for something asynchronous may not be properly run to completion. This can be surprising and, also, because this only happens in cases of cancelation, which could happen at any moment, could be a major source of subtle bugs.
The downside of forbidding cancelation is that in some cases a release operation might block indefinitely and this can also cause issues. However, I believe those cases will be both harder to miss (your program hangs rather than leaks) and easier to debug (a debugger or stack trace should be able to point you to the release call).
I was previously undecided on whether it should be done implicitly, but it has turned out to be surprising, so, now I'm convinced that the right thing to do is to forbid cancelation propagation during resource
releasecalls.The issue is that if a fiber gets canceled, then resource
releaseoperations that might need to await for something asynchronous may not be properly run to completion. This can be surprising and, also, because this only happens in cases of cancelation, which could happen at any moment, could be a major source of subtle bugs.The downside of forbidding cancelation is that in some cases a
releaseoperation might block indefinitely and this can also cause issues. However, I believe those cases will be both harder to miss (your program hangs rather than leaks) and easier to debug (a debugger or stack trace should be able to point you to thereleasecall).Thanks to @faldor20 for asking about this!