Názory k článku Knihovny libmill a libdill: implementace korutin a kanálů pro jazyk C

Děkuji za hezký článek, taky se s podobnými věcmi potýkám, takže dobrý odkaz na nastudování.

Chápu dobře, že pod kapotou budou standardní pthready + futexy + možná nějaké hrátky se stackem kolem yield() nebo i kanálů, takže při volání knihovních funkcí coroutine safety == thread safety?

A jednu podstatnou otázku:
ve všech příkladech kdy čekáte na několik corutin, používáte konstrukci stylu choose ... otherwise sleep(něco); což pro praxi není moc hezké (buď se tam zavede zbytečný delay, ať už z samotného čekání, nebo z toho že kernel neví že proces už dočekal a má se přeplánovat právě na něj)

Existuje v tomhle případě možnost čekat i přes nějaký synchronizační objekt (interně na Linuxu by dával smysl futex, ale to je věc knihovny) čekat na několik corutin současně?

Implementovat určitě ano, , ale můžete mě zkusit nasměrovat kde by taková implementace byla reálně použitelná v céčku?
otázkou směřuju k tomu, že coby člověk dělající v céčku jsem celkem konzervativní, a používám ty koncepty které mi přinesou nějakou viditelnou výhodu (resp jsem donucenej je použít).
U coroutiny (nebo jí podobné implementace) je pro mě třeba jasná výhoda, pokud do ní můžu offloadovat nějaké pomalé zpracování a nemusím se starat, jak nějaký algoritmus rozdělit na krátké slicy apod. ale jen si pak sáhnout pro výsledek Jako příklad mějme hru, NPC se rozhodne dojít z místa A do dost vzdáleného místa B, pathfinding je dost pomalý ale nevadí, že potrvá několik sekund, nutná podmínka je aby těch několik sekund běželo na jiném vlákně než hlavní loop hry kde záleží na každé mikrosekundě (pokud je mapa statická etc. ale nekomplikujme to detaily) -> aby to pro mě dávalo smysl, musí to běžet v nejméně dvou threadech -> musím pak _nějak_ řesit i thread safety.
(to _nějak_ nemusí nutně znamenat thread-safe, i "všechna volání knihovny musí být ze stejného threadu" je použitelné, ale je potřeba to vědět.)