Consider if `::resume()` should be check block state

[kammce]

This is for both context::resume which applies to the resume function on future<T>. context::resume() will resume if and only if the blocked_by state is nothing.

[kammce]

Actually this brings up a flaw in sync_wait because we don't have a way for sync wait to know how long to delay resumption for.

[kammce]

I realized yesterday that sync wait has a major issue. Below is a summary generated by Claude Sonnet 4.5 regarding why I believe we need to remove sync wait OR maybe remove blocking by external which I do not like.

Why Remove sync_wait()

Core issue: sync_wait() assumes single-context, deterministic execution. blocked_by::external breaks this:

future<void> my_coro(context& ctx) {
  co_await some_std_task();  // blocked_by::external
}
ctx.sync_wait(my_coro);  // DEADLOCK - external needs this thread

Why workarounds fail:

• Yielding/spinning doesn't help - external coroutine needs CPU time
• Returning control on external just makes user implement a scheduler

Recommendation: Remove sync_wait() from framework. Use explicit execution models:

simple_context::run();        // inline blocking
scheduler.run_until_complete();  // event loop
test_context::step_until_done(); // testing

Note: Simple context performs a thread sleep when a scheduled time delay has occurred. It returns control if it reaches a blocked by external state.

Makes execution model visible. No hidden limitations. Proper multi-context coordination lives where it belongs - in schedulers.

[kammce]

From some preliminary benchmarking with a state check within resume, it seems that nothing changed much in terms of runtime. I get real numbers from my m1 Mac and put them here once I have a PR that passes its test without needing sync_wait.

[kammce]

Actually, we can make one change to allow sync_wait to work and to make external a pollable blocking state. The idea is simple. A coroutines that starts an 3rd party coroutine cannot await it. It must manage it until its finished. The coroutine becomes a 3RD party supervisor and must perform the same actions as a proxy, which is to keep itself as the active coroutine and resume the coroutine as needed (if possible) and wait until the coroutine has finished its work. The responsibility of ensuring that the coroutine returns and that users have an expectation of what to do when this coroutine is called is up to the writer of the coroutine itself. This means that anything that blocks by external is pollable and the schedulers allow it to call it and resume it however it likes.

This would make it blocked by external, a, pollable, and a hint to the scheduler, meaning that the only blocking state that actually requires a time like deadline is blocked by time.