Hacktoberfest 2026：メンテナが10月に向けて印を付けた、オープンで初心者向けの issue。 Hacktoberfest の issue を見る

Discuss shared broadcast receives without a Clone bound

オープン
  • 何か問題がありますか？
#312 コメント 5 件 リアクション 0 件 担当者 0 名 GitHub で見る

メンテナーはふだん 1 日以内に返信

@orthur2 がすでに取り組んでいます。

2026年10月11日 から。

  • #359 @orthur2 による — オープン

評価

難易度
5/5
見積もり時間
1週間以上
初心者へのやさしさ
30/100
issue の種類
機能追加
明瞭さ
説明が足りない
活発さ
活発
技術スタック
rust
領域
backend-api-design

調査の方向性

Start by reading asyncband/src/broadcast/mpmc/common.rs, especially the shared backlog and take_msg, then compare the bounded and unbounded receiver APIs. Resolve whether shared receives should be added and how they interact with existing owning receives; done requires an accepted API direction plus validation of non-Clone fan-out, cancellation, capacity release, and existing receive behavior.

索引モデルが issue の本文から書いたものです。

説明

enhancement question

Problem

Both bounded and unbounded broadcast currently require T: Clone at construction and return T from recv / try_recv. Multiple subscribers need access to each published value, but requiring an owned T for every receive is an API choice rather than a requirement of the backing storage.

The shared backlog already stores VecDeque<Arc<T>>. Receiving obtains an Arc<T>, and take_msg converts it to T: it clones the payload when needed and attempts to move it out when the message is reclaimed. Payload cloning and destruction happen outside channel locks.

Callers can already use T = Arc<State> without requiring State: Clone, but the internal representation then becomes Arc<Arc<State>>. Exposing shared ownership of the existing message could avoid the additional Arc layer.

This issue is an open design discussion. The API below is a candidate, not an accepted implementation specification.

Candidate: add shared receives and preserve owning receives

Relax the T: Clone bound on both constructors. On both receiver types, add methods available for any T:

pub async fn recv_shared(&mut self) -> Result<Arc<T>, RecvError>;
pub fn try_recv_shared(&mut self) -> Result<Arc<T>, TryRecvError>;

Keep the existing recv and try_recv methods returning T, with T: Clone required only for those methods.

The two receive forms would consume from the same subscription cursor. Choosing a return representation would neither create a new subscription nor deliver the same message twice to one subscription. Bounded and unbounded channels should expose consistent APIs.

Compatibility

  • Relaxing constructor bounds preserves existing calls and permits non-Clone payloads.
  • Adding shared receive methods preserves the existing owning API. As with any new Rust inherent method, a name collision with a downstream extension trait is a possible compatibility edge case; see the Cargo guidance.
  • Changing the existing recv / try_recv return type to Arc<T>, or renaming the old methods to give their names to shared receives, breaks existing callers.
  • Preserve the existing move-out optimization. Implementing owning receives as an unconditional clone of a shared receive would lose the current guarantee that a channel with a single receiver does not clone its payload.
  • At this discussion's starting point, unbounded broadcast is present in v0.7.2, while bounded broadcast was added for the next release in #253. Changing only the unreleased bounded API would not break a released API, but would leave the two channel variants inconsistent.

Semantics and tradeoffs

Shared receives must preserve message ordering, cancellation safety, disconnection behavior, and capacity accounting. Reclaimed bounded capacity must be released before running payload clone or drop callbacks.

Once every subscription has consumed a message or been dropped, the message can leave the backlog and release its queue capacity. An Arc<T> retained by a caller can nevertheless keep the payload allocation alive. Bounded capacity would limit retained backlog messages, not all memory held by completed receives.

A shared result gives subscribers ownership of the same allocation. An owning result gives them a T according to that type's Clone semantics, which need not be a deep copy. These are useful distinct contracts, but exposing both adds API surface and commits the shared path to Arc-based ownership.

Keeping the current API and asking callers to choose T = Arc<State> remains an alternative. It keeps the public API smaller at the cost of the extra Arc layer. Replacing owning receives with shared receives gives one default ownership model, but requires an explicit breaking-change decision.

Questions to resolve

  1. Is avoiding payload Clone requirements and nested Arc storage worth adding a permanent shared receive API?
  2. Are recv_shared / try_recv_shared the right names and the right place to express the ownership choice?
  3. Should we adopt the additive design, retain the current caller-selected Arc approach, or consider a shared-by-default API in a future incompatible release?

If the additive design is selected, validation should cover non-Clone payload fan-out, mixed shared and owning receives on one cursor, cancellation, bounded capacity release while returned Arcs remain alive, and preservation of existing owning-receive behavior.

Related: #311 narrows Watch's constructor bound without changing its return-value ownership model. Part of the channel-family discussion in #206.

主要言語
Rust
スター
283
フォーク
49
平均マージ
1日 9時間
マージ済み PR（30日）
39

環境構築

このプロジェクトには開発コンテナ、Dockerfile、コントリビューションガイドがありません。まず README を読み、一般的な手順ははじめてのコントリビューションガイドを参照してください。

はじめの一歩

  1. issue を最後まで読み、次にプロジェクトのコントリビューションガイドを読みます。
  2. 着手することを issue にコメントします — 二人が同じ作業をするのを防げます。
  3. リポジトリをフォークし、ブランチを切って変更します。
  4. issue 番号を参照したプルリクエストを送ります。

apache/asyncband のほかの issue

apache/asyncband の issue をすべて見る

似ている issue

Rust の issue をもっと見る

新しい issue をメールで受け取る

初心者向けの GitHub issue を短くまとめたダイジェスト。