| |||||||||||||
CoroutinesCoroutinesPosted May 8, 2012 19:19 UTC (Tue) by robert_s (subscriber, #42402)In reply to: Coroutines by geertj Parent article: nPth - The new GNU portable threads library
You clearly didn't get enough of cooperative multitasking the first time around.
(Log in to post comments)
Coroutines Posted May 9, 2012 2:12 UTC (Wed) by jamesh (guest, #1159) [Link]
Cooperative multi-tasking at the operating system level between independent applications has obvious problems with one application starving the others for CPU time if it doesn't yield.
Things are a bit different if you're talking about cooperative multi-tasking within a single application though: if the application is controlling all the co-routines, then those sort of bugs should be predictable and fixable. Co-routines can greatly simplify some programming tasks: letting you use the stack to manage state, while not having to deal with the complexities of concurrent execution in the same address space.
Coroutines Posted May 9, 2012 12:37 UTC (Wed) by geertj (subscriber, #4116) [Link]
> Things are a bit different if you're talking about cooperative multi-tasking within a single application though: if the application is controlling all the co-routines, then those sort of bugs should be predictable and fixable.
Exactly - this is the key difference. And it's not like the different threads in a multi-threaded program don't need to cooperate. They can just as easy starve each other if e.g. they do not correctly cooperate in locking.
|
|||||||||||||