Yuri Finkelstein

in lldb: ``` Process 98425 stopped * thread #2, stop reason = EXC_BAD_ACCESS (code=2, address=0x700001fa6fd0) frame #0: 0x000000010028c708 cppcoro_tests`(anonymous namespace)::local::get_resumable_waiter_count(state=) at async_auto_reset_event.cpp:33 30 } 31 32 constexpr std::uint32_t get_resumable_waiter_count(std::uint64_t state)...

given the recursion depth it's probably not important where exactly it crashes though.

The crash happens both in debug and release builds

if thread pool size is changed from 3 to 1 ``` cppcoro::static_thread_pool tp{ 1 }; ``` at the top of the test, the crash does not happen any more

> provide a scheduler I was long wondering how come this library can exist without a notion of a scheduler like the one necessary for stackfull coroutines such as https://www.boost.org/doc/libs/1_69_0/libs/fiber/doc/html/fiber/scheduling.html...

And btw, `adaptive` (http://lkml.iu.edu/hypermail/linux/kernel/0103.1/0030.html) type of mutex in pthread on Linux uses Futex under the covers. So, direct linking with futex API is probably not the best solution.

I'have a generic brain-dead implementation ready. It's sort of hard to get wrong given c++ native support. Header: add section for CPPCORO_OS_GENERIC ``` /////////////////////////////////////////////////////////////////////////////// // Copyright (c) Lewis Baker //...

Re build, I obviously need something to build the above on Mac. So I put together a basic cmakelist file. I'm also new to cmake but it feels a good...

I will fork and submit a PR once I have the tests passing.

As an afterthought, this case is a good candidate for a reader/writer lock. There is a single writer invoking set flag and multiple readers checking and waiting for the set...