Guido van Rossum wrote:
I'm with ghazel on this one. Long, long ago I used a system that effectively used implicit cocalls. It was a threading OS with non-preemptive scheduling, so instead of locking you'd just refrain from calling any one of the (very few) syscalls that would allow another thread to run.
What this says to me is that the mindset of "I'm using cooperative threading, so I don't need to bother with locks" is misguided. Even with non-preemptive scheduling, it's still a good idea to organise your program so that threads interact only at well defined points using appropriate synchronisation structures, because it makes the program easier to reason about. Anyway, the scheme I'm proposing is not the same as the scenario you describe above. There are some things you can be sure of: a plain function (defined with 'def') won't ever block. A function defined with 'codef' *could* block, so this serves as a flag that you need to be careful what you do inside it. If you need to make sure that some section of code can't block, you can factor it out into a plain function and put a comment at the top saying "Warning -- don't ever change this into a cofunction!" So you effectively have a way of creating a critical section, and a mechanism that will alert you if anything changes in a way that would break it. I think this is a better approach than relying on call markers to alert you of potential blockages. Consider that to verify whether a stretch of code inside a cofunction is non-blocking that way, you need to scan it and examine every function call to ensure that it isn't marked. Whereas by looking up the top and seeing that it starts with 'def', you can tell immediately that blocking is impossible. -- Greg