Peter Maydell <peter.mayd...@linaro.org> writes: > On 22 June 2012 13:04, Markus Armbruster <arm...@redhat.com> wrote: >> Peter Maydell <peter.mayd...@linaro.org> writes: >> >>> On 22 June 2012 09:48, Markus Armbruster <arm...@redhat.com> wrote: >>>> In my opinion, coroutines have been useful for us so far. Whether they >>>> remain useful, or serve us just as a stepping stone towards general >>>> threads remains to be seen. >>> >>>>From my point of view I've seen a whole pile of problems and not >>> really any advantages... >> >> Advantages over what? > > Over what we had before we had coroutines. I know there are > advantages, I'm just saying that personally I've been largely > on the downside rather than the upside.
Granted. Just saying that there's an upside, too :) >>> I particularly think it's a really bad >>> idea to have a complex and potentially race-condition-prone bit >>> of infrastructure implemented three different ways rather than >>> having one implementation used everywhere -- it's just asking >>> for obscure bugs on the non-x86 hosts. >> >> Fair point, but it's an implementation problem, not a fundamental >> problem with coroutines. You *can* implement coroutines portably, >> e.g. on top of gthread. > > If you're implementing them on top of separate threads then > you just have an obfuscated API to threads. No, what you really have is yet another means to express control flow. The fact that it can be implemented on top of threads doesn't necessarily make it an obfuscated API to threads. Look, a while loop isn't an obfuscated API to continuations, either. It's less general, but when it's all you need, it's easier to use. When all you need is coroutines, not having to worry about preemption makes them easier to use in my experience.
