when_any question
まだ誰も着手していません。
評価
調査の方向性
まず exec/when_any.hpp と、stop_when およびキャンセルに関する P2300 の議論を読みます。提供されている reproducer を実行して、負けた sender が停止されるかどうかを確認します。期待されるキャンセルのセマンティクスが確立され、文書化または実装され、その動作をカバーするテストがあることをもって完了とします。
索引モデルが issue の本文から書いたものです。
説明
when_any(job1,job2) completes when either job1 or job2 complete.
I was hopeful that when one of the senders completes, the other would be stopped..
Testing that hypothesis with
#include <chrono>
#include <fmt/core.h>
#include <exec/static_thread_pool.hpp>
#include <exec/when_any.hpp>
#include <stdexec/execution.hpp>
using namespace std::chrono_literals;
int main()
{
exec::static_thread_pool pool(4);
stdexec::scheduler auto sch = pool.get_scheduler();
stdexec::sender auto job1 = stdexec::schedule(sch) | stdexec::then([](){
int i{0};
while (true) {
fmt::print("job1: {}\n", i++);
std::this_thread::sleep_for(200ms);
}
});
stdexec::sender auto job2 = stdexec::schedule(sch) | stdexec::then([](){
for (int i = 0; i < 5; ++i) {
fmt::print("JOB2: {}\n", i);
std::this_thread::sleep_for(500ms);
}
});
stdexec::sync_wait(exec::when_any(job1,job2));
}
suggests that this isn't the case.
Bug or feature? Should my job1 be looking for a stop_token in the environment?
I note that P2300 mentions stop_when and doesn't mention when_any. I am guessing that they are synonyms?
- 主要言語
- C++
- スター
- 2.4k
- フォーク
- 270
- 平均マージ
- 2日 10時間
- マージ済み PR(30日)
- 42
コントリビューションガイド
このリポジトリのコントリビューションガイドは索引されていません
はじめの一歩
- 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
-
bug build
難易度 1/5 1時間未満 初心者へのやさしさ 91/100
facebookincubator/velox#19194 ·
-
JIT-compiled number -> Decimal conversion silently overflows instead of raising DECIMAL_OVERFLOW オープンfuzz
難易度 2/5 1〜3時間 初心者へのやさしさ 82/100
ClickHouse/ClickHouse#122114 ·
-
難易度 2/5 1〜3時間 初心者へのやさしさ 84/100
-
module/agent platform/macos type/bug/regression
難易度 2/5 1〜3時間 初心者へのやさしさ 88/100
-
enhancement PyCDE
難易度 2/5 1〜3時間 初心者へのやさしさ 78/100