Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Feature : recv and send methods for the request_reply sockets that takes a mutable reference of the RequestReceiver and the RequestSender #41

Open
eldoccc opened this issue Jul 20, 2023 · 1 comment
Labels
enhancement New feature or request

Comments

@eldoccc
Copy link

eldoccc commented Jul 20, 2023

I believe recv(mut self) and send(mut self, mut msg: Multipart) in the request_reply sockets were designed to take self instead of &mut self so you cannot make multiple send before getting the reply and rcv before sending the reply.
However in the case of tokio::select! inside of a loop :

let (tx,rx) = mpsc::channel(64);

loop {
            tokio::select! {
                _  = rx.recv() => {}
                _  = request_receiver.recv() => {}
            }
        }

because recv() consumes self, the compiler won't allow for it to be used in this case.

A barbaric solution would be to spawn a task containing the recv() and use channels to communicate back and forth with the select!, however i'd rather have an appropriate method for this case.

Without wanting to alter the current structure, a quick fix for me was the create a struct RequestReply contaning both the send(&mut self, mut msg: Multipart) and the recv(&mut self) methods in the cloned repo.

@cetra3
Copy link
Owner

cetra3 commented Jul 20, 2023

Yeah I'm not sure whether it's cancel safe at the moment, which is what is required for select!, but definitely interested if there's a solution here.

@cetra3 cetra3 added the enhancement New feature or request label Jul 20, 2023
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
enhancement New feature or request
Projects
None yet
Development

No branches or pull requests

2 participants