You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
This commit was created on GitHub.com and signed with GitHub’s verified signature.
Documentation
say where the semver gate lives and that breaking changes bump by hand
correct the feature graph and drop the --all-features line
drop default from the feature graph
drop the editorialising above the feature-graph notes
draw the feature graph instead of describing it
add health files and complete the crate metadata
drop the in-repo pointers into the internal plans directory
Fixed
(client) keep servicing sends while an inbound delivery is blocked
Fixed
Client socket loop no longer deadlocks against the client run loop when
its inbound channel fills. Each socket's I/O loop forwards received
datagrams into a bounded channel of 16 and used to .await that hand-off
inline, which stopped it from servicing its outgoing-send queue. The client
run loop is the only reader of the SD socket's inbound channel and awaits
the completion of every SD send (Subscribe, SendSD) on that same socket,
handling control messages ahead of discovery. So once more than 16 SD
datagrams arrived during a run of Subscribes, each loop waited on the other
forever: no further sends, events or subscription renewals. The socket loop
now keeps the pending delivery as a future and selects over it alongside the
send queue, with receiving paused until the delivery lands. Sends keep
flowing while the reader is busy, at most one parsed datagram is held,
nothing is dropped, and both inbound and outbound ordering are unchanged.