In concurrencpp, the coroutine handle is wrapped by the await_via_functor which acts kinda like a uinque_ptr for the coroutine handle. cleaning the coroutine is up to the developer, coroutine_handle acts as a C-like pointer and nothing more. The problem which this object, that besides referencing the coroutine, it does nothing itself. errors::runtime_shutdown is anyways not well tested in the context of global scope.Īccording to the standard, every coroutine is associated with a coroutine_handle which acts as its this pointer. From my current understanding removing errors::runtime_shutdown and maybe renaming broken_task exception to interrupted_task exception should be the way to go. I am sadly not an expert on this topic as well, but it is the only logical explanation I have. The exception will be broken_task_exception.ĭo we need the errors::runtime_shutdown exception? I assume now that the bad behavior happening during stack unwinding during exception handling. In case I disable throwing shutdown and instead early return, shutdown works always. I realized that it always SEGFAULTS in case throw_runtime_shutdown_exception will be called and thrown. I tried to find out, where the difference is between a working shutdown and a failing shutdown. I investigated further and have a question.Īfter adding more debug prints inside of the code, it becomes more and more of a race if shutdown works or not. For that, I refactored a little bit everything. Before they do anything, I will check if the shutdown was requested. I added checks for the do_* functions inside of the executor. In case an executor is shut down, it does not spawn a new task anymore. But at least I found a workaround for me. Sadly I could not find the root cause, I hope you can find it. But now the problem is the same dtor will be called shortly after destroy again, why we have a double deletion, which causes SEGFAULT.Ĭould not find out why this happening, because my knowledge regarding coroutines is still too weak. This magic seems to be normal with coroutines, but still don't know why. This destruction method seems to trigger as well result_coro_promise dtor. Because of the unique_ptr_deleter, done_stroy() will be called in delete_self of result_state. Then the result type will be destroyed, which has a pointer of the result_state in result_coro_promise. During this execution, it realized somehow that it needs to be canceled. What happening is, that even in case a shutdown is called the inner task will be still executed.
0 kommentar(er)
