Async Option

[VoreckLukas]

Having the option to use this libraries functions in an async context would be great. To that end I forked the repo and am working on implementing it behind a feature flag. if you got some advice, I'm open to hear it

[kladd]

An async interface does make sense. I haven't spent much time thinking about this, but replacing the use of std::net's TcpStream with the TcpStream from tokio would be a start. The Stream module might be tricky, though. For example, the wait() function blocks on a Condvar, so this might need to be rewritten to use tokio::sync::Notify or similar—and I'm not sure at the moment if/how that streams data structure would need to change to support that.

[VoreckLukas]

I already started the rewrite. I have a particular problem i haven't gotten to debug yet:
When trying to connect (Client::new) I see that it is connected inside of ksp but my test seems to be deadlocked at that line. Should I open a draft pull request to track this or keep it on my local branch, separate from this repo until im ready

[VoreckLukas]

As for the Condvar thing: i used this for now: https://crates.io/crates/tokio-condvar
Mostly cause I want to get it to work first, then I might rewrite around Notify

[VoreckLukas]

I found the issue: due to CodedInputStream Not supporting tokios tcp stream I had to rewrite

#[cfg(not(feature = "async"))]
fn recv<T: protobuf::Message + Default>(
    rpc: &mut TcpStream,
) -> Result<T, RpcError> {
    CodedInputStream::new(rpc)
        .read_message()
        .map_err(Into::into)
}

A read_to_end blocks endlessly cause it waits for a EOF a single read crashes cause it doesn't read enough. I'll look into how to decode the length delimiter

[VoreckLukas]

Fixed that issue, next issue is as you predicted: Streams don't work. I'll look into that when I got time again

[VoreckLukas]

False alarm, it was an issue with my rocket lol. Streams work. I'll try to rewrite the condvar with notify and then I think it's ready for use

[VoreckLukas]

Resolved with #17