Skip to content

memory leak without cancellation #10

@rzbdz

Description

@rzbdz

When io_context destructs, theasync_scope is not co_await joined , thus the coroutine frame on heap might not be cleaned when the detached coroutine is not finished.

see: https://togithub.com/CarterLi/liburing4cpp/issues/27
see: https://en.cppreference.com/w/cpp/coroutine/coroutine_handle/destroy
see: https://stackoverflow.com/questions/68352718/is-it-necessary-to-call-destroy-on-a-stdcoroutine-handle

A possible solution for cancellation (I 've seen this before, maybe in boost.asio)

cancellation_source src  (just like stop_source & stop_token, and the cancellation token is supported in Task of C#)
awaitable frame 1: a cancellation_token bind to the src
  awaitable frame 2: a cancellation_token bind to the src
   awaitable frame 3: a cancellation_token bind to the src
    .....
      io_uring/user space timer/thread_pool a cancellation_token bind to the src

Once the coroutine calling stack (stackless linked-list of coroutine_handles) is suspended by a io event (on io_uring/user space timer/thread_pool ), say this awaitable could be a non-lazy task (thus we have a eager started future concept(check here), it's start to run asynchrounously, but there is no need to wait), then we just pass the user_data of io_uring or some timer token of timer or some thread_pool token of thread_pool to the original src, thus all the awaitable along the calling stack could get a token bind the a same user_data or sth (just like what shared_ptr does), then we got O(1) complexity to update the user_data along the way, but when it comes to the when_all supports, it fails.

More investigation and trying would be done.

Metadata

Metadata

Assignees

Labels

bugSomething isn't working

Projects

No projects

Milestone

No milestone

Relationships

None yet

Development

No branches or pull requests

Issue actions