3 ms·
With coroutines you know when your task switches. You have clear explicit points in your program for that. That makes resources sharing and error handling way e
by sametmax 8y ago
With coroutines you know when your task switches. You have clear explicit points in your program for that. That makes resources sharing and error handling way easier and predictible.
In threads, anything goes. Anywhere. That's basically goto, but worse because you can't know when the goto happens or where.
Even nurseries, which work great to scope coroutine execution, are nowhere as straightforward with threads.
- ur-whale 8y ago>With coroutines you know when your task switches. Yes, obviously. >That makes resources sharing and error handling way easier and predictible. I am actually not so sure about that. With threads, you code knowing fully that your code can be pre-empted anywhere. It's uniform and simple. With co-routines, you have to think about the additional logic of when to yield, and that's very distracting. As a matter of fact, I tend to create more deadlocking code in a co-routine environment than in a threaded one, because - among other things - I'm permanently tempted to get clever.
- blattimwind 8y ago> I am actually not so sure about that. With threads, you code knowing fully that your code can be pre-empted anywhere. It's uniform and simple. The model of threads is fairly simple, but that does not mean that it is simple to program for. In practice developers don't do very well at reasoning about locking.