Consider an opt-in `asyncband::block_on` module

[tisonkun]

Motivation

asyncband deliberately exposes runtime-agnostic async primitives and avoids adding a blocking variant for every primitive. Users who need a small synchronous facade currently have to choose and depend on a separate executor just to block on an operation such as Mutex::lock.

For a future release, consider providing a lightweight, opt-in bridge based on pollster:

• A free block_on function that runs an IntoFuture to completion while parking the current thread.
• A FutureExt extension trait that supports the suffix-style .block_on() call.

The API could tentatively live under asyncband::block_on:

use asyncband::block_on::{block_on, FutureExt as _};

let guard = block_on(mutex.lock());
let guard = mutex.lock().block_on();

This would let users build convenient synchronous wrappers around async primitives without adding blocking methods to every primitive.

Constraints and open questions

• The API must be disabled by default and enabled through an opt-in Cargo feature.
• The default asyncband API and build dependency tree should remain unchanged.
• This should remain a lightweight single-future executor, not a general-purpose async runtime.
• Documentation should clarify that futures depending on runtime-specific drivers may not make progress, and that blocking from an async executor thread can cause starvation or deadlocks.
• asyncband::block_on, the Cargo feature name, and whether to adapt the implementation or use an optional dependency are tentative design choices.

This issue records a direction to consider for a later release, rather than a commitment to a specific API or release.

[jiengup]

That's a good idea.
And I propose that maybe we can add an API like this:

fn block_on_timeout(self, timeout: Duration) -> Result<Self::Output, Timeout>

to prevent starvation or deadlocks.

[tisonkun]

@jiengup Thanks for your feedback :D

A timer is more complicated than you may consider.

I spawn fast/scorpio for a schedule agnostic IO context project. That is, any timeout in Async Rust would be associated with a timer context, and acting like:

runtime::block_on(async {
  select! {
     timeout_future => ...,
     primitive_action_futrue => ...,
  }
});

So I'd keep that away from asyncband's core API, unless you can propuse a proper solution here.

[tisonkun]

But we may leverage park_timeout in the pollster style parking based solution.

@jiengup Would you like to dig into more details?

[jiengup]

But we may leverage park_timeout in the pollster style parking based solution.

@jiengup Would you like to dig into more details?

Sure, I'm interested in it. I'll try my best to work it out.
@tisonkun Any guidance or references on that?

[tisonkun]

@jiengup I think the best way is sending this thread to an agent and let it demo and explain to you 😆

Then you may send a draft PR and/or we can discuss on concrete items.

[jiengup]

@jiengup I think the best way is sending this thread to an agent and let it demo and explain to you 😆

Then you may send a draft PR and/or we can discuss on concrete items.

Got it hah.
I'll try and organize some considerations first for further discussion.