[Jasper_]

Multiple methods in that snippet use something like:

    while(true) {
        Animate(image);
        wait 200;
    }

implies there are multiple synchronous execution stacks. It's not threading, as the synchronization points are explicit.

[_0ffh]

>synchronization points are explicit

Hmmm, I'd have just called it cooperative threading/multitasking then. Or do you think that would be wrong?

[TeMPOraL]

It wouldn't. That's literally what coroutines are. In-process, lightweight, cooperative multitasking, built in as a language feature (or at least close enough to it).

[DagAgren]

It is not. Coroutines are a much more fundamental feature. They can be used to implement cooperative multitasking, and since that is such a common use case, they have gotten confused with the concept of cooperative multitasking.

Actual coroutines are a lot more flexible and interesting than just cooperative multitasking, though.

[_0ffh]

Erm, I'm pretty sure I can implement coroutines using cooperative multitasking. Also, the other way around. So I'd say they're equivalent in that sense.

[DagAgren]

Cooperative multitasking usually involves a scheduler. Coroutines are called explicitly, which you can't do through a scheduler.

[_0ffh]

Now you're really just making claims about implementation details. That doesn't make one concept more "fundamental" or "flexible" than the other, while "interesting" is just a subjective judgement.

[TeMPOraL]

With coroutines, your program logic itself is the scheduler.

[ghusbands]

Coroutines and cooperative threading/multitasking are indeed threading. I assume they meant to say that it was neither preemptive nor parallel, which makes it somewhat limited. Some people think a system has to be one or both of those to be called threading.

[Jasper_]

For me, and for a vast majority of people I'd say, the word "threading" in common parlance implies pre-emptive scheduling with implicit synchronization points.

[gpderetta]

cooperative threading is just coroutines plus a scheduler.