-
-
Notifications
You must be signed in to change notification settings - Fork 5.5k
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
IO: tie lifetime of handle field to container #43218
Conversation
Rather than freeing this memory as soon as possible, ensure that the lifetime of the handle is always >= the container object. This lets us examine some (limited) aspects of the handle without holding a lock. And we also examine and fix numerous other thread-safety and synchronization bugs too.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I don't fully understand this part of code so all I can do is some nitpicks
This appears to have broken CI. |
I tried re-opening the PR but that doesn't appear to work. Probably best to do a new PR to revert the revert with whatever fixes are required to not break CI. |
Yeah, GitHub doesn't want to have 2 merges from a single PR. I was working on figuring this out locally, and will push a new PR when I have solved it. |
Rather than freeing this memory as soon as possible, ensure that the lifetime of the handle is always >= the container object. This lets us examine some (limited) aspects of the handle without holding a lock. And we also examine and fix numerous other thread-safety and synchronization bugs too.
…" (JuliaLang#43924) This reverts commit 5cd31b5.
Rather than freeing this memory as soon as possible, ensure that the lifetime of the handle is always >= the container object. This lets us examine some (limited) aspects of the handle without holding a lock. And we also examine and fix numerous other thread-safety and synchronization bugs too.
…" (JuliaLang#43924) This reverts commit 5cd31b5.
Rather than freeing this memory as soon as possible, ensure that the
lifetime of the handle is always >= the container object. This lets us
examine some (limited) aspects of the handle without holding a lock.
And we also examine and fix numerous other thread-safety and
synchronization bugs too.