4 ms·
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
by brobdingnagians 8y ago
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 );
...
}
- ur-whale 8y ago>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.
- blattimwind 8y ago> 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.
- akvadrako 8y agoThat's not a good reason. That is virtual address space, not physical memory, and processes have plenty of it, usually about 280TB.
- jnwatson 8y agoYou 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.