可以移除 ViaCoroutine ?

[yanminhui]

Search before asking

• I searched the issues and found no similar issues.

What happened + What you expected to happen

每次调用 RescheduleLazy 为了恢复到调用前所在的上下文，会通过 ViaAsyncAwaiter 附带一个恢复的协程 ViaCoroutine。
这个恢复的协程的逻辑是否可以合并到 FinalAwaiter，避免需要多调用这个协程？

Reproduction way

Anything else

Are you willing to submit a PR?

• Yes I am willing to submit a PR!

[ChuanqiXu9]

ViaCoroutine 的主要用途是 co_await 用户自定义的 awaiter 时可以切换回来。

[yanminhui]

ViaCoroutine 的主要用途是 co_await 用户自定义的 awaiter 时可以切换回来。

SimpleExecutor e;

Lazy<void> bar() {}

Lazy<void> foo() {
    co_await bar.via(&e); // 这个不属于用户定义的，但每次都要附带 `ViaCoroutine` 协程。
}

[ChuanqiXu9]

ViaCoroutine 的主要用途是 co_await 用户自定义的 awaiter 时可以切换回来。

SimpleExecutor e;

Lazy<void> bar() {}

Lazy<void> foo() {
    co_await bar.via(&e); // 这个不属于用户定义的，但每次都要附带 `ViaCoroutine` 协程。
}

指的是非 Lazy 类型的其他 Awaiter

[yanminhui]

指的是非 Lazy 类型的其他 Awaiter

我的意思是像上面这种是否可以解决不需要附带 ViaCoroutine。

另，对于你说的非 Lazy 的 Awaiter，detail::coAwait(ex, awaitable) 是否可以根据是否存在 ex 来决定是否需要 ViaCoroutine ?

[ChuanqiXu9]

指的是非 Lazy 类型的其他 Awaiter

我的意思是像上面这种是否可以解决不需要附带 ViaCoroutine。

RescheduleLazy 按设计其实本来只有 ReschduleLazy.start() 这种用法的，co_await RescheduleLazy; 不在设计范围内，所以我觉得针对这种 case 进行优化并没必要。如果可以的话，可以加一些约束，让我们只能 DetachedCoroutine 中 co_await RescheduleLazy，我记得这样会好一些。我添加了一个相关的 issue：#163

另，对于你说的非 Lazy 的 Awaiter，detail::coAwait(ex, awaitable) 是否可以根据是否存在 ex 来决定是否需要 ViaCoroutine ?

无法判断其他 awaiter 中是否有 ex。如果你说判断 ex 是否非 null 的话，那本来就会判断吧。

[ChuanqiXu9]

这里的 executor 指的是 context 的 executor 而不是 awaiter 的 executor

[yanminhui]

对，我们看下上面这个代码片段，虽然有一个 executor，但它是 nullptr，没有人给它贱值，假设上面那个 UserAwaiter 切到其它线程去 resume，经过 ViaCoroutine 也回不到原来所在的线程，这个 ViaCoroutine 看起来没有意义。

[ChuanqiXu9]

空 executor 的情况属于预期外行为，除了我们在测试中会使用 syncAwait 以外，实际运用时都要加上 via 指定调度器的。同时就算是这种情况，ViaCoroutine 也不会造成逾期外行为。目前看应该没有必要对这种 edge case 进行优化。

[RainMark]

其实不太建议用户去自定义awaiter，应该是用future awaiter去和系统现有的异步接口去对接

[RainMark]

ViaCoroutine更多是一种正确性保证。确保默认情况下协程经过了自定义awaiter就能正确回到之前的线程。毕竟业务逻辑上不一定都是允许同一个协程跨线程执行。如果业务逻辑确定可以lazy挂起恢复前后被任意调度，那么用户自定义executor可以不实现checkin即可满足。另外不传executor的确是预期外行为，因为lazy后处理逻辑全在回调线程里立即执行了，一方面会有lazy跨线程执行风险，另一方面大量后处理任务可能回调线程（例如io线程池组）