Feasability of fork topology without `split`
まだ誰も着手していません。
評価
調査の方向性
まず issue のトポロジーと split ベースの例を確認し、次に P3682 を読んで std::execution::split の削除案を理解してください。共有ノードのグラフを、別の依存関係なしに残りの stdexec の機能を使って表現できるかどうかを判断してください。実行可能な表現を提供するか、それが不可能な理由を文書化すれば完了です。
索引モデルが issue の本文から書いたものです。
説明
We'd like to represent the following topology (each node represents some work):
graph TD
A --> B
A --> C
B --> D
C --> D
C --> E
D --> END
E --> END
It seems that for such a case, it is possible to use split:
auto A = just() | then(...) | split();
auto B = A | then(...);
auto C = A | then(...) | split();
auto D = when_all(B, C) | then(...);
auto E = C | then(...);
sync_wait(when_all(D, E));
However, P3682 (written by @RobertLeahy) proposed to remove std::execution::split and as far as we understand it, it was approved.
Therefore, how would we represent the above topology, without introducing other dependencies ?
Joint question with @maartenarnst.
- 主要言語
- C++
- スター
- 2.4k
- フォーク
- 270
- 平均マージ
- 2日 16時間
- マージ済み PR（30日）
- 43
コントリビューションガイド
このリポジトリのコントリビューションガイドは索引されていません
はじめの一歩
- issue を最後まで読み、次にプロジェクトのコントリビューションガイドを読みます。
- 着手することを issue にコメントします — 二人が同じ作業をするのを防げます。
- リポジトリをフォークし、ブランチを切って変更します。
- issue 番号を参照したプルリクエストを送ります。
NVIDIA/stdexec のほかの issue
-
inline_scheduler's namespace-scope static_assert fails under nvcc (private nested __sender access) オープン
難易度 2/5 1〜3時間 初心者へのやさしさ 65/100
-
難易度 2/5 1〜3時間 初心者へのやさしさ 68/100
-
難易度 4/5 3〜5日 初心者へのやさしさ 45/100
-
難易度 4/5 3〜5日 初心者へのやさしさ 48/100
-
難易度 4/5 3〜5日 初心者へのやさしさ 65/100
似ている issue
-
難易度 2/5 1〜3時間 初心者へのやさしさ 75/100
flutter-webrtc/flutter-webrtc#2206 ·
-
難易度 2/5 1〜3時間 初心者へのやさしさ 70/100
google-ai-edge/LiteRT-LM#3739 ·
-
Component: GLib
難易度 2/5 1〜3時間 初心者へのやさしさ 70/100
-
難易度 2/5 1〜3時間 初心者へのやさしさ 65/100
brave/brave-browser#59300 ·
-
Mute ydb/tests/functional/dstool/test_canonical_requests.py.Test.test_group_take_snapshot in main オープンai_reviewed
難易度 2/5 1〜3時間 初心者へのやさしさ 70/100
ydb-platform/ydb#53974 · コメント 3 件 ·