News for hackers. Stuff that matters.
Re:Libaco: A fast and lightweight C asymmetric coroutine lib... by brobdingnagians on Saturday July 14, 2018 @04:23AM (#17529389)
For front-end UI code I'd just use threads, but if you want to do a lot of concurrent network calls on a constrained server, coroutines will use your resources a lot better. Using boost::asio you can use a yield_context to write code without callbacks and makes it a lot less complex to keep in your head (looks just like normal code!). You might be able to use something like this in threads, but I love the format for writing server code.

void doSomething( yield_context& yc ){ auto db_res1 = doDatabaseCall( "SELECT * FROM tops", yc ); auto db_res2 = doNetworkThing( yc ); ... }

Re:Libaco: A fast and lightweight C asymmetric coroutine lib... by ur-whale on Saturday July 14, 2018 @07:14AM (#17529844)
>coroutines will use your resources a lot better

Maybe, but I'm not actually sure why. Worker threads are pretty darn cheap on modern OS's.

Also - may it's just me - but I've always found co-routine based apps harder to debug: your stack is a weird tangle of unrelated things and figuring out what's going on is harder than with threads.

Re:Libaco: A fast and lightweight C asymmetric coroutine lib... by blattimwind on Saturday July 14, 2018 @08:15AM (#17530010)
> Maybe, but I'm not actually sure why.

Mainly because stackless coroutines do not require separate stacks for each thread of execution. The default stack size in Linux is iirc 2 MB but grows as required, of course.

Re:Libaco: A fast and lightweight C asymmetric coroutine lib... by akvadrako on Saturday July 14, 2018 @10:22AM (#17530447)
That's not a good reason. That is virtual address space, not physical memory, and processes have plenty of it, usually about 280TB.
Re:Libaco: A fast and lightweight C asymmetric coroutine lib... by jnwatson on Saturday July 14, 2018 @11:39PM (#17533674)
You have a very small number of values that can stay in L2 cache on a 2 MiB boundary, 12 on Skylake. The data TLB is only 4 way. Modern high performance software is about cache management, and spreading your data across swaths of page-aligned memory without strong control of when you get scheduled out underutilizes that most precious resource on the CPU.