Make SendRequest Sync #221
Open
Conversation
This file contains 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
SendRequest is clone-able and Send-able which is convenient for applications to store/embed SendRequest in their own structures and use that from different async tasks. This would also mean that if the application is sharing reference to their structures (that has a SendRequest inside) across tasks, then SendRequest would need to be Sync too. It will be really really convenient to have SendRequest as Sync or else the applications will basically have to wrap the SendRequest in Arc<Mutex<>> SendRequest has the "open" element which implements OpenStreams, and these are basically Stream futures. Streams are not Sync, there is plenty of discussions on related topics in this link - https://internals.rust-lang.org/t/what-shall-sync-mean-across-an-await/1202 I am not exactly sure why the OpenStreams methods are implemented as futures that are stored in SendRequest, why cant they be implemented as open_foo() calls into the underlying quinn connection from the pollers in OpenStreams. I am assuming there is a good reason for that (which I am interested in learning), and hence if we want to retain these are stored futures, then basically I am doing a SyncWrap of those here
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.
SendRequest is clone-able and Send-able which is convenient for applications to store/embed SendRequest in their own structures and use that from different async tasks. This would also mean that if the application is sharing reference to their structures (that has a SendRequest inside) across tasks, then SendRequest would need to be Sync too. It will be really really convenient to have SendRequest as Sync or else the applications will basically have to wrap the SendRequest in Arc<Mutex<>>
SendRequest has the "open" element which implements OpenStreams, and these are basically Stream futures. Streams are not Sync, there is plenty of discussions on related topics in this link - https://internals.rust-lang.org/t/what-shall-sync-mean-across-an-await/1202
I am not exactly sure why the OpenStreams methods are implemented as futures that are stored in SendRequest, why cant they be implemented as open_foo() calls into the underlying quinn connection from the pollers in OpenStreams. I am assuming there is a good reason for that (which I am interested in learning), and hence if we want to retain these as stored futures, then basically I am doing a SyncWrap of those here