Are Futures blocking the runtime?

[jonatan-zeidler-bl]

I tried to find answers in #17, but it doesn't seem to answer my question, nor does the suggestions there seem to match the current API design.

As a user of the zenoh API (or any API), I try to reason about whether a function is

1. evaluated immediately, or
2. needs to wait for something (other task/thread or resource) and whether it does so in a
   1. blocking or
   2. asynchronous way, either
      1. via a callback (sync), or
      2. a runtime waker (async/await)

Looking at zenoh types I have a hard time to figure that out. For example, sending a query reply goes through the ReplyBuilder which I need to await on. As a Rust developer, this tells me we are in case 2. ii) b), the normal Rust async world. From that I also take it that I am probably waiting for the network to send out the reply, potentially suffering back-pressure (which would be nice to be found documented in the API docs btw).

But looking at the implementation, I get a different impression:

impl IntoFuture for ReplyBuilder<'_, '_, ReplyBuilderPut> {
    type Output = <Self as Resolvable>::To;
    type IntoFuture = Ready<<Self as Resolvable>::To>;

    fn into_future(self) -> Self::IntoFuture {
        std::future::ready(self.wait())
    }
}

with

/// Synchronous execution of a resolvable
pub trait Wait: Resolvable {
    /// Synchronously execute and wait
    fn wait(self) -> Self::To;
}

This reads like the ReplyBuilder is turned into a directly-ready-future that simply calls synchronous code. Does that mean we are actually in case 1.? If so, why the Future in the first place and what about back-pressure? Or are we in 2. i.? That would be bad news as it would be blocking the Runtime, wouldn't it?

[jonatan-zeidler-bl]

Turns out that this pattern is really a bug.