-
Notifications
You must be signed in to change notification settings - Fork 299
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
[ESI][Runtime] Teardown: memory ownership #7457
Labels
Comments
teqdruid
added a commit
that referenced
this issue
Aug 7, 2024
Add a poll method to ports, a master poll method to the Accelerator, and the ability to poll from the service thread. Also, only spin up the service thread if it's requested. The service thread polling (in particular) required some ownership changes: Accelerator objects now belong to the AcceleratorConnection so that the ports aren't destructed before the service thread gets shutdown (which causes an invalid memory access). This particular binding isn't ideal, is brittle, and will be an issue for anything doing the polling. Resolving #7457 should mitigate this issue. Backends are now _required_ to call `disconnect` in their destructor.
teqdruid
changed the title
[ESI][Runtime] Teardown: ownership
[ESI][Runtime] Teardown: memory ownership
Aug 7, 2024
teqdruid
added a commit
that referenced
this issue
Aug 8, 2024
Add a poll method to ports, a master poll method to the Accelerator, and the ability to poll from the service thread. Also, only spin up the service thread if it's requested. The service thread polling (in particular) required some ownership changes: Accelerator objects now belong to the AcceleratorConnection so that the ports aren't destructed before the service thread gets shutdown (which causes an invalid memory access). This particular binding isn't ideal, is brittle, and will be an issue for anything doing the polling. Resolving #7457 should mitigate this issue. Backends are now _required_ to call `disconnect` in their destructor.
teqdruid
added a commit
that referenced
this issue
Aug 8, 2024
Add a poll method to ports, a master poll method to the Accelerator, and the ability to poll from the service thread. Also, only spin up the service thread if it's requested. The service thread polling (in particular) required some ownership changes: Accelerator objects now belong to the AcceleratorConnection so that the ports aren't destructed before the service thread gets shutdown (which causes an invalid memory access). This particular binding isn't ideal, is brittle, and will be an issue for anything doing the polling. Resolving #7457 should mitigate this issue. Backends are now _required_ to call `disconnect` in their destructor.
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
When an
AcceleratorConnection
is torn down and destructed, accesses to its associatedAccelerator
s and their associated ports will be memory violations. This is (fairly) well documented in the API, but isn't ideal.Accelerator
shouldn't be owned byAcceleratorConnection
. The associated ports should merely throw exceptions on accesses to disconnected or destructed connections.The basic idea is that
Accelerator
and everything accessible from it should merely be a facade.The text was updated successfully, but these errors were encountered: