All the polls needs &mut ! - poll_close/poll_accept_request/poll_accept_datagram - hows that supposed to work?

[gopakumarce]

So I see that in the webtransport example, the connection is under a Mutex I guess to workaround the fact that all the poll_xyz() needs &mut .. But how will that work in practise where I have a connection from which lets say I am doing something like below

select!{
    _ = poll_accept_request => {/* got new request */}
    _ = poll_accept_datagram => {/* got new dgram */}
    _ = poll_close => {/*drive the state machine */}
}

This wont work because all the arms need to be mutable, and the connection is not clone-able either .. So what is the thought process behind how something like this can be done ?

[gopakumarce]

I guess all this stems from the fact that the h3-quinn Connection for example has all the opening/incoming etc.. implemented as Streams, and streams need a mutable reference to do get_next() .. If not for the stream way of doing it (not sure why its done using streams), the quinn Connection itself is clone-able and does not need &mut. So without the stream way of doing things, all this could have been done without a need for &mut I guess - I can do some rework around this area if someone can clarify that the stream is not needed

[gopakumarce]

tagging a few people who have worked on it recently and in the past - @Ruben2424 / @seanmonstar / @stammw - I see that the origin of the "stream" is from Quinn itself when quinn used to provide IncomingUniStreams/IncomingBiStreams structures and I guess at some point quinn got rid of those in favor of quinn conn.accept_uni() conn.accept_bi() and at that point maybe to maintain the same style of code as before it got replaced to just streams locally within h3 that point ?

Now that quinn conn.accept_uni() and conn.accept_bi() takes an &self and returns a new stream, do we still need to have these streams - can we just move to use those APIs instead ? I cant cut a PR if that sounds reasonable