Skip to content

Comments

Feat: replace BlockCell with watch channel#397

Open
julio4 wants to merge 3 commits intofeat/async_payload_builderfrom
feat/replace_blockcell
Open

Feat: replace BlockCell with watch channel#397
julio4 wants to merge 3 commits intofeat/async_payload_builderfrom
feat/replace_blockcell

Conversation

@julio4
Copy link
Member

@julio4 julio4 commented Feb 20, 2026

Stacked on #394

📝 Summary

With #394, try_build is now an async method and we can use proper async channels and .await for flashblock timing signals.

  • Replaced BlockCell with tokio::sync::watch channel. The builder publishes its best payload to the watch channel after each completed build (fallback block + each flashblock).
  • resolve_kind can reads the latest best payload value instantly with borrow.
    • ResolvePayload resolves immediately with the pre-fetched value instead of acquiring lock/polling channel.
    • However if there's no value yet (fallback block not published), it waits on watch::Receiver::changed() until the first Some(best_payload) is published
  • deprecate build_complete field (we never poll it anywhere).

💡 Motivation and Context

The current BlockCell implementation use Mutex<Option<T>> + Notify for sharing the best payload between the builder task and engine get payload. WaitForValue::poll calls cx.waker().wake_by_ref() on every poll when no value which i think produces a waker spin loop instead of yielding back to executor and Mutex adds unnecessary resource locks (as we have only one directional PayloadBuilder publisher -> PayloadResolve consumer)


// check if self.cell has a payload
self.cancel.cancel();
info!("Resolve kind {:?}", kind);
Copy link
Collaborator

Choose a reason for hiding this comment

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

not sure if we still need this log

Copy link
Contributor

Choose a reason for hiding this comment

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

Maybe we can make it more informative but we should still have something that indicates the getPayload call

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