Open isidorostsa opened 1 month ago
This minimal example can be used to reproduce the 2nd issue.
Alternatively, it can also be reproduced by running any of the following unit tests:
tests.regressions.modules.executors.bulk_sync_wait
tests.unit.modules.execution.algorithm_as_sender
tests.unit.modules.executors.explicit_scheduler_executor
tests.unit.modules.executors.scheduler_executor
tests.unit.modules.executors.thread_pool_scheduler
with one of these command line arguments:
--hpx:threads=1
or--hpx:queuing=<policy>
with <policy>
being either static
, static-priority
, local-workrequesting-fifo
or local-workrequesting-mc
. (These are the policies among those that I was able to test on my machine where deadlocking happened. But I suspect that any non-workstealing policy leads to this issue.)
Remaining issues
std
synchronization primitives, which clash with HPX's (e.g.stdexec::run_loop
,this_thread::sync_wait
usestd::mutex
andstd::condition_variable
. This causes some tests to deadlock. Thanks to @zhekemist for identifying this! The following commit fixed a bug caused by this interaction: https://github.com/STEllAR-GROUP/hpx/pull/6431/commits/d06c9ad13aca0ed38e77e08fa2664290389fbc4e.algorithm_transform_mpi
andmpi_ring_async_executor
have been disabled due to issue # 2 highlighted above. Other tests may be failing too, but it was noticed that there are MPI tests that fail but doreturn 0
so they are not marked as failing. This should be corrected too.Due to these issues, Stdexec won't be enabled by default. To activate there needs to be an explicit definition:
HPX_WITH_STDEXEC=ON