event_task and continuation about asyncplusplus HOT 5 CLOSED

The issue here is that task unwrapping is done on the default scheduler rather than inline. This results in the continuation running in the main thread pool instead of in your main thread.

This behavior was introduced in 4879059 because a long chain of unwrapped tasks could cause a stack overflow in some situations.

from asyncplusplus.

Thank you, for the clarification. The issue is that current thread might have more context associated with it than the thread from the thread pool. E.g. in my case i use thread_local data to store a handle to an event loop object. In my opinion letting the client code to drive the thread selection will be optimal.

from asyncplusplus.

As a temporary workaround you can revert 4879059, which should bring back the old behavior of keeping everything in a single thread. I will look into solving this properly.

from asyncplusplus.

Does this behavior only exist if I use the inline scheduler?

I'm hoping that the default pool is never used if I always explicitly provide a scheduler.

from asyncplusplus.

I'm just going to revert 4879059, it's causing too much trouble.

from asyncplusplus.