Skip to content

Add SendFut::into_inner.#126

Open
NathanSWard wants to merge 1 commit into
zesterer:masterfrom
NathanSWard:nathan/sendfut-into-inner
Open

Add SendFut::into_inner.#126
NathanSWard wants to merge 1 commit into
zesterer:masterfrom
NathanSWard:nathan/sendfut-into-inner

Conversation

@NathanSWard
Copy link
Copy Markdown

This is the first step for adding a send_timeout_async and send_deadling_async.
This provides the ability to consume a SendFut returning its contained value if the value has not yet been sent.

@zesterer
Copy link
Copy Markdown
Owner

This looks good to me! I initially turned my nose up at the name into_inner, but on second thoughts I think you're right that this does actually follow the conventions set by other types in the Rust ecosystem.

@zesterer
Copy link
Copy Markdown
Owner

At least now, building a timeout on top is a relatively trivial job. In terms of implementing that, I think the most lightweight and sensible solution - based on a cursory reading - is to pull in the async-io crate as an optional dependency and use its timers (perhaps behind some sort of async_timeout feature in flume). What do you think?

@NathanSWard
Copy link
Copy Markdown
Author

Yep, it mostly just depends on how you want the API to look either
A) having the function be marked async

pub async fn send_timeout_async(&self, message: T, dur: Duration) -> Result<(), ErrorType>;

B) having the function return some concrete type that implements Future

pub fn send_timeout_async(&self, message: T, dur: Duration) -> TimeoutFut;

In the case of A we could just use async_std::future::timeout I believe, and then in case B, async-io would be a good solution yes!

@zesterer
Copy link
Copy Markdown
Owner

I think B is probably the way to go. It's an underrated thing, but being able to name the type of a feature is occasionally very important, particularly if you're building an API on top of the thing.

@NathanSWard
Copy link
Copy Markdown
Author

@zesterer Do you want these as separate MRs, or should I add the timeout functions here in this MR?

@NathanSWard
Copy link
Copy Markdown
Author

It looks like the actual implementation of the _async functions make take a bit of extra work.
Notably, the Hook type has a todo comment: // TODO: Investigate some sort of invalidation flag for timeouts.

When writing tests, for the implementation, there is a panic coming from the fire_recv function which always unwraps the inner value.

@tqwewe
Copy link
Copy Markdown

tqwewe commented Mar 27, 2025

Are there any updates to this? I'm looking to use flume in kameo, but sadly this feature is a bit of a blocker for me.

Comment thread src/async.rs
}

/// Consume `self` returning the queued value if it has not yet been sent.
pub fn into_inner(mut self) -> Option<T> {
Copy link
Copy Markdown

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Could this be &mut self, or is it intentionally consuming the SendFut?

Copy link
Copy Markdown
Owner

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think it can be made to accept &mut self, yes.

@zesterer
Copy link
Copy Markdown
Owner

I'm so sorry, GitHub swallowed my notification for this.

@zesterer Do you want these as separate MRs, or should I add the timeout functions here in this MR?

The MR is fine as-is, I think. @tqwewe's suggestion seems sensible though!

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

3 participants