Repository navigation
Conversation
…nstead of blocking Dropping a DeviceFuture whose work is still in flight used to synchronize the stream on the dropping thread, which under select!/timeout is an executor thread. The result is a handle by the DeviceOp::execute contract (every device-visible resource is retained by the submission), so it is released immediately; the execution context is parked with the completion reactor behind a flag write enqueued after the abandoned work and released on a dedicated reaper thread when the flag lands. The reactor only hands off, never releases. If the context cannot be parked it is dropped inline, which is the previous blocking wait; faulted and capturing streams still leak the owners with a report (quiet when the fault was already delivered). reaper::parked() and reaper::reaped_total() expose the counts. Signed-off-by: Melih Elibol <elibol@users.noreply.github.com>
|
Auto-sync is disabled for draft pull requests in this repository. Workflows must be run manually. Contributors can view more details about this message here. |
This was referenced Oct 8, 2026
This branch has not been deployed
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Transplant of NVlabs/cutile-rs#305 (NVlabs/cutile-rs#305) onto cuda-rust after the repository move: one commit, original author and sign-off, host-crate paths following the move to the repository root.
Draft for review and record; not targeted at 0.4.0.
Dropping an in-flight
DeviceFutureno longer synchronizes the stream on the dropping thread (an executor thread underselect!/timeout). The result is released immediately: by theDeviceOp::executecontract every device-visible resource is already retained by the submission, so the result is a handle. The execution context is parked with the completion reactor behind a flag write enqueued after the abandoned work and released on a dedicated reaper thread when the flag lands; the reactor only hands off. Fallbacks are unchanged in effect: a context the reactor cannot take is dropped inline (the previous blocking wait), and faulted or capturing streams still leak the owners with a report, quiet when the fault was already delivered.'staticbound on outputs and no userDropon our threads: only theExecutionContextis parked.cuda_async::reaper::parked()/reaped_total()for observability.