We currently maintain a list of stream IDs that may have data to send separately from the list of streams themselves. Removing streams from this list isn't practical since their position is unpredictable. In #1196 this tripped us up as other code assumed a nonempty list guaranteed that a stream could send, even though that stream might have been reset.
Replacing the stream ID list with an intrusive list of streams would allow streams to robustly remove themselves from the list as needed. The same pattern might be applicable to e.g. StreamsState::connection_blocked and maybe even Retransmits::max_stream_data. These are traditionally a difficult data structure in rust due to the ownership/access ambiguity they introduce, but we should review what solutions to that have been developed, if any.
We currently maintain a list of stream IDs that may have data to send separately from the list of streams themselves. Removing streams from this list isn't practical since their position is unpredictable. In #1196 this tripped us up as other code assumed a nonempty list guaranteed that a stream could send, even though that stream might have been reset.
Replacing the stream ID list with an intrusive list of streams would allow streams to robustly remove themselves from the list as needed. The same pattern might be applicable to e.g.
StreamsState::connection_blocked
and maybe evenRetransmits::max_stream_data
. These are traditionally a difficult data structure in rust due to the ownership/access ambiguity they introduce, but we should review what solutions to that have been developed, if any.