3 ms·

.. why would they be broken ? coroutines are not related to threads

• grogers 4y ago
  I think the point is that if the coroutine suspends it could be resumed on a different thread. So you don't really want to mix thread locals and coroutines.
  • jcelerier 4y ago
    I mean, for sure but that's not a property of coroutines, any callback system can do that e.g. if you have this code with boost: #include <boost/asio.hpp> #include <chrono> #include <vector> #include <thread> #include <iostream> std::mutex print_mutex; int main() { using namespace boost::asio; using namespace std::literals; io_context io_context(20); auto work_guard = make_work_guard(io_context); for(int i = 0; i < 100; i++) { post(io_context, [&] { thread_local int x = 0; int z = x++; std::lock_guard _{print_mutex}; std::cout << z << "\n"; }); } std::vector<std::jthread> v; for(int i = 0; i < 20; i++) v.emplace_back([&] { io_context.run_for(2s); }); } i hope you don't expect the output to be "0, 1, 2, ..., 99"
    • deleted 4y ago
      [deleted]
• malkia 4y ago
  state, e.g. assuming that there is single flow of operations, and nothing gets swapped out (logically). This breaks with co-operative scheduling systems - e.g. task thread while waiting on I/O (for example) gets reused for some other task, hence they get to see the same thread_local, and somewhere someone assumed "thread_local" == "task_local" of sorts (but not).