Offer a way to free resources in uninterruptible way by default and opt-out ability to interrupt #53

Activity

1. arybczak commented on Sep 2, 2026

   

   arybczak

   on Sep 2, 2026

   Last edited by arybczak

   Contributor

   More actions

   While it's unfortunate that this caused issues in your prod environment (and I'm sure it wasn't fun to debug), ultimately it's client's job to ensure that resource creation and destruction is asynchronous exception safe. If a library has a latent bug like this, it's enough to use a bracket instead of this library to trigger the bug.

   Hedis: informatikr/hedis#275 with its informatikr/hedis#276.

   As I wrote in the comment there, this is unrelated to this change, it was always a problem because this library never ran resource creation within uninterruptibleMask.

   I think the best we can do is to communicate loudly in a documentation that resource creation and destruction need to be asynchronous exception safe.

   👍React with 👍1Reacted by Andrey Prokopenko
2. arybczak commented on Sep 2, 2026

   

   arybczak

   on Sep 2, 2026

   Contributor

   More actions

   extend pool configuration with a flag that indicates how to handle pool resource destroying

   This doesn't help, because either

   1. you set up pool internally and you might as well fix your functions so they work everywhere, instead only with pooling, or
   2. you use the pattern from README and then the user controls whether resources leak or not, or you take the resulting pool and override this setting, at which point you can also fix your functions like in (1).
3. cdfa commented on Sep 9, 2026

   

   cdfa

   on Sep 9, 2026

   More actions

   ultimately it's client's job to ensure that resource creation and destruction is asynchronous exception safe

   That's true, and indeed bracket also leaves it up to the user to ensure this.
   But I still think it's hard to do it correctly, and we should try to help clients where we can.
   Mentioning it in the documentation would help for sure, but it would be much better if the behaviour that prevents the most prod issues is the default.
   So I'm wondering: is being interruptible the best default for resource release actions? I think it makes sense that a program is interruptible at any point by default, but specifically for release actions I think being uninterruptable by default makes more sense.
   I think most release actions are fast as long as there are no operational issues going on, so in most cases it shouldn't be an issue to wait. And as I said, it could prevent real-world issues (and that's worth something even if the root cause is in client code).

   You can also look at it this way: technically, you're always supposed to keep in mind whether the release function contains interruptible functions like those mentioned in bracket's docs. If you are aware of those, it's just as easy to make those uninterruptible (in the case where the default for release functions are not masked uninterruptible by default) as it is to escape the mask using withAsyncWithUnmask. But if you're not aware of some interruptible function in your release function, it's probably better off being uninterruptibleMasked.

   The argument is the same for bracket itself, so I'm aware I may be holding an unpopular opinion, but I thought it would be worth discussing nonetheless.