refactor(server): deliver USB completions through shared per-device state - #1808
Open
uchouT (uchouT) wants to merge 3 commits into
Open
refactor(server): deliver USB completions through shared per-device state#1808uchouT (uchouT) wants to merge 3 commits into
uchouT (uchouT) wants to merge 3 commits into
Conversation
github-actions
Bot
added
maintainer-required
The lifecycle, pending-request map and USB shared state now live in a single Arc<ServerUsbDevice> inside the handle. Signed-off-by: uchouT <i@uchout.moe>
A transmitted request is always answered by a completion, and handling that completion is what releases its tracking state. A request that never reached the transport is never answered, so it needs an explicit release. This is distinct from cancel_request, which stops a request already in flight and must not release anything. Signed-off-by: uchouT <i@uchout.moe>
The RDPEUSB backend now resolves a pending request directly through the shared per-device state, so IoComp is gone from UrbdrcDeviceServerMessage and completions no longer queue behind requests waiting on a socket write. Signed-off-by: uchouT <i@uchout.moe>
uchouT (uchouT)
force-pushed
the
urbdrc/server-comp
branch
from
August 27, 2026 16:43
1ee732c to
efb660a
Compare
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.
Reworks how
ironrdp-servertracks a redirected USB device, so thatcompletions no longer round-trip through
ServerEvent.Per-device state (lifecycle, pending-request map, USB shared state) moves into
a single
Arc<ServerUsbDevice>held byUsbDeviceHandle. The event loop'srouter shares that state instead of owning a separate record.
The RDPEUSB backend now resolves a pending request directly through that shared
state, and
UrbdrcDeviceServerMessage::IoCompis gone. A completion is alreadyfully decoded when the backend receives it, and delivering it needed nothing the
event loop owns; previously it was re-queued and could sit behind requests
waiting on a socket write. An I/O submission is also answered before its write,
so the caller owns cancel-on-drop as early as possible.
UrbdrcDeviceServer::abandon_unsentreleases a request that was built but neverhanded to the transport. Such a request is never answered by a completion, so
nothing else would ever release its tracking state. This is deliberately
separate from
cancel_request: a cancelled request is still answered, with afailure HRESULT per [MS-RDPEUSB] sections 3.3.5.3.1 and 3.3.5.3.6, so cancelling
must not release anything.
Two notes for review.
RawPendingis no longer re-exported fromironrdp-server; it had no public constructor and no public producer, so nodownstream could obtain one, and this removes an unreachable export rather than
a usable API. Teardown now drains pending requests explicitly, because the
pending map outlives the router entry that used to own it and dropping that
entry no longer fails the waiting callers on its own.