Hacker News Reader

Comment by dingdingdang | Hacker News Reader

Can someone help elucidate why "It's a non-goal for Neco to provide a scalable multithreaded runtime, where the coroutine scheduler is shared among multiple cpu cores [...]" this library even makes sense then? When I use coroutines in Go it is invariably in order to make use of more CPU cores when extra performance needs to be extracted.

View on HN

Goroutines aren't coroutines. This isn't a nitpick, it's pretty essential to understanding the goals and non-goals of Neco.

Coroutines are a control-flow primitive which allows for a lot of useful things, including advancing program state while a coroutine waits on a syscall, generators, iterators, producer-consumer patterns with channels, and combinations of these things. They generalize function calls, or structure goto, if you prefer.

Some of these applications are glossed as concurrent, particularly their use to free the thread when execution blocks, but all of them are single-threaded. Goroutines are preëmptively scheduled, and can be relocated between threads transparently. That isn't really a coroutine, which is why they have a different name.

The README has some notes on how to use Neco coroutines in a multithreaded environment. It's basically how you'd run execution paths of multiple function calls on several threads, because coroutines are an orthogonal concern to threads.

The library rightly leaves implementation of that up to the user. You're talking about mixing cooperative and preemptive threads which have very different safety and execution profiles. There are many ways to arrange and interact the two things. Trying to provide general support for something like that would just end up a complicated mess that no one actually understands properly.

the scheduler is probably simpler if coroutines can't bounce between cores. you can have a single thread per core that runs the scheduler to multiplex a bunch of coroutines on the single thread, which lines up with the example linked in the repo to a redis clone. redis runs a single thread (i think technically it has some multithreading stuff now but that was the model for a while) but can concurrently process a bunch of requests like when 1 or more requests are blocked on blpop, a pubsub thing, xread with block arg given, etc. nginx does something similar with forking a process per core that runs single threaded (ignore the threading for stuff that reads from disk).

Also it is possible to start multiple Neco schedulers in different threads, there’s an example in the readme.

yeah i like this model. then you can use whatever synchronization junk you prefer to share state between the threads, if you have any.

your library looks well written and clean. thanks for sharing.

if anyone else wants to go coroutine spelunking, these were interesting to me:

https://github.com/higan-emu/libco/tree/master

https://github.com/Tencent/libco

https://github.com/hnes/libaco

https://kernel.googlesource.com/pub/scm/virt/kvm/qemu-kvm/+/...

https://tia.mat.br/posts/2012/09/29/asynchronous_i_o_in_c_wi...

https://www.cs.uml.edu/~bill/cs516/context_paper_rse-pmt.pdf

Coroutines are still very useful for multitasking even if you're not sharing tasks between CPU cores. Other coroutines can just execute whenever something would normally block, removing the need for multiple threads in the first place.

This library aims to be the simplest and most efficient thing for what it does. And what it does is perfect for is managing communications with things that themselves may be bound by I/O.

Handling multiple threads to access multiple CPUs would make it far more complex. And frankly a single thread is plenty for handling, say, a chat server.

coroutines as a control flow construct within a thread are quite useful.

Reply on news.ycombinator.com