1

The thing is that when there are coroutines they can work in random order, and they can end up but

BOOST_LOG_NAMED_SCOPE(...)

keeps scope's name on each stackframe being oblivious to the fact that those stackframes are not nested, so they can be destructed in any order, not to mention that it's not that hard to put on a scenario where the scope according to boost::log::named_scope is different from the actual one.

How to make boost:log compatible with boost::coroutine and boost::context ?

unegare
  • 2,197
  • 1
  • 11
  • 25

1 Answers1

1

Named scopes in Boost.Log are maintained per-thread, using a thread-local storage, and consequently are incompatible with coroutines.

If you want a similar functionality with coroutines, you will have to implement a separate attribute that maintains a list of scopes in a coroutine-local storage. You can use Boost.Intrusive to implement the list itself. On Windows, you could use fiber-local storage to place the list. On other systems you will probably have to use the stack.

The above applies to stackful coroutines. Stack-less coroutines do not have a dedicated stack, so it is not possible to maintain a dedicated list of scopes that pertains to activity of a given coroutine.

Andrey Semashev
  • 10,046
  • 1
  • 17
  • 27
  • 1
    I *think* it's possible to have state - including dynamically allocated - in custom C++20-coro promise types. In fact, ASIO likely already uses that to contain associated (inner) executor, cancellation slot and allocator. – sehe Jan 16 '23 at 15:47
  • @sehe, BEST IDEA EVER! (on state) – unegare Jan 17 '23 at 19:32
  • @unegare I looked at it yesterday. It seems like you'll have to come up with a custom macro that uses the name_scope sentry on a scoped_logger_guard instead of scoped_thread_guard, but that should work. You might go all in and create an awaitable that returns the coro logger instance (like `co_await this_coro::logger`) – sehe Jan 17 '23 at 21:40