Hacker News Reader

Comment by hiyfsch | Hacker News Reader

Just because coroutines exist doesn’t mean everything should use them for concurrency.

Why would it be better? It’s pretty easy to set up threads in general.

Threads use more system resources than coroutines so it can be a big deal when you can potentially have thousands of them running.

Yeah I guess also depends on the problem space. For example, dedicated threads doing something versus a bunch of short-lived asynchronous tasks that need scheduling anyhow.

If a bunch of tasks need to be schedule best not to have to reinvent the wheel on that if possible.

If there’s longer running tasks the benefits probably are less noticeable.

The management to handle Threading and IO and not get it wrong is pretty high unless you’re using something like Rust because it guarantees you’re safe, vs letting the routine runtime management handle everything for you for free

Nah, coroutines/async/etc often lives in various threads (ie, the workers can schedule one of them on different threads during the lifetime and they live concurrently), so you still have all the issues of threading (+ new ones since things like thread-local variables aren't reliable if an async/coroutines moves threads between calls).

The main benefit is not having the cost of threads, f.ex. a default thread on Windows has something like 500k of stack iirc, scale that to 10000 concurrent requests and you're looking at 5gb of memory _just for stacks_, compared to a couroutine,etc that has perhaps a few kb's of usage (even if in deep stack-traces).

This is why we have stuff like io_uring these days, the bottleneck moved to the kernel calls (especially with Spectre style attacks) when concurrent costs in the applications went down.

> Nah, coroutines/async/etc often lives in various threads (ie, the workers can schedule one of them on different threads during the lifetime and they live concurrently), so you still have all the issues of threading (+ new ones since things like thread-local variables aren't reliable if an async/coroutines moves threads between calls).

In cooperative scheduling how is it possible to have two coroutines running concurrently?

You're thinking of older early coroutines or in singlethreaded runtimes (JS).

It's M:N threading, most logical threads/tasks are more lightweight than full OS threads, the logical ones should preferably behave cooperatively but they can be scheduled onto any number of real worker threads (usually these systems picks something like 2x worker threads compared to real CPU/Core count to manage some codepaths not being as well behaved).

Erlang and .NET(with Task/async) uses this model, iirc modern Java does this also (but hides it) and I'd be surprised if the modern async Rust or C++ variations didn't do this as well.

C++20 co-routines model is based on .NET ones, as the original model was proposed by Microsoft and inspired on WinRT work.

If you know how to create asyncable types on .NET, the magic methods expected by C++ compiler will feel familiar.

You mean in the sense that async methods return "awaitable" (Value)Task objects that contains the actual activation machinery that can be queried for liveness status?

It's funny that they're actually revamping the entire machinery for .NET 11 to defer allocations by default for non-waiting codepaths (Not sure, but iirc that machinery might require JIT compilation so would've perhaps not been possible to use for C++).

> aren't reliable if an async/coroutines moves threads between calls

Then just don't move them between threads and you're good with thread locals, no?

Iirc often the frameworks don't have worker affinity, anyhow environments like .NET has "AsyncLocal" to provide an aware alternative.

Reply on news.ycombinator.com