Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Implement UnwindSafe by never returning on panic #239

Draft
wants to merge 3 commits into
base: master
Choose a base branch
from

Conversation

fabianfreyer
Copy link

Don't return objects to the pool on panic, since we can't be sure whether they were the source of the panic.

See-also: #139

Don't return objects to the pool on panic, since we can't be sure
whether they were the source of the panic.

See-also: bikeshedder#139
@fabianfreyer fabianfreyer mentioned this pull request Feb 20, 2023
@fabianfreyer fabianfreyer marked this pull request as draft February 20, 2023 23:02
@bikeshedder
Copy link
Owner

I think you accidentally mixed the managed and unmanaged implementations.

The Drop implementation of deadpool::managed::Object needs to be changed and the UnwindSafe marker needs to be added to the deadpool::unmanaged::Pool for both implementations to be deemed unwind safe.

@fabianfreyer
Copy link
Author

Hmm, I guess both should have the marker then?

@bikeshedder
Copy link
Owner

I'm just revisiting this as part of a overall repository clean-up. Not returning objects on panic is a good idea for the managed pool. For the unmanaged pool hower this could cause some rather pesky side effects. It's unmanaged for a good reason: You create all the objects you need and then just use them forever. If a panic doesn't crash the application altogether it might end up with an empty pool waiting forever.

One way I could think about was the following:

  • managed pools don't return the object if the code panicked. Though they still need to make sure to notify the pool about the slot being available!
  • unmanaged pools should probably enter a panicked state and all future calls to get should panic as well. Maybe make this configurable somehow?

It's just my gut feeling that discarding objects on panic only ever makes sense if panics are handled and then you really need to make sure that the pool gets refilled. I can imagine only very few users would expect that to be the case.

@bikeshedder bikeshedder force-pushed the master branch 2 times, most recently from 2f4d3ba to b1cf396 Compare March 31, 2024 22:51
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

2 participants