when_any question
Nobody has claimed this yet.
Assessment
- Difficulty
- 4/5
- Estimated time
- 3-5 days
- Newbie friendliness
- 30/100
Research direction
Start by reading exec/when_any.hpp and the P2300 discussion of stop_when and cancellation. Run the supplied reproducer to observe whether the losing sender is stopped. Done means the expected cancellation semantics are established and either documented or implemented, with tests covering the behavior.
Written by the indexing model from the issue text.
Description
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?
- Dominant language
- C++
- Stars
- 2.4k
- Forks
- 270
- Avg merge
- 2d 10h
- Merged PRs (30d)
- 42
Contributor guide
No contributing guide indexed for this repository
First steps
- Read the whole issue, then the project's contributing guide.
- Comment on the issue to say you are picking it up — it saves two people doing the same work.
- Fork the repository and make your change on a branch.
- Open a pull request that references the issue number.
More from NVIDIA/stdexec
-
inline_scheduler's namespace-scope static_assert fails under nvcc (private nested __sender access) Open
Difficulty 2/5 1-3 hours Newbie friendliness 65/100
-
Difficulty 2/5 1-3 hours Newbie friendliness 68/100
-
Difficulty 4/5 3-5 days Newbie friendliness 45/100
-
Difficulty 4/5 3-5 days Newbie friendliness 48/100
-
Difficulty 4/5 3-5 days Newbie friendliness 65/100
Similar issues
-
bug build
Difficulty 1/5 Under an hour Newbie friendliness 91/100
facebookincubator/velox#19194 ·
-
JIT-compiled number -> Decimal conversion silently overflows instead of raising DECIMAL_OVERFLOW Openfuzz
Difficulty 2/5 1-3 hours Newbie friendliness 82/100
ClickHouse/ClickHouse#122114 ·
-
Difficulty 2/5 1-3 hours Newbie friendliness 84/100
-
module/agent platform/macos type/bug/regression
Difficulty 2/5 1-3 hours Newbie friendliness 88/100
-
enhancement PyCDE
Difficulty 2/5 1-3 hours Newbie friendliness 78/100