Hacker News new | ask | show | jobs
by trebecks 805 days ago
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).
1 comments

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