[Python-ideas] Cofunctions PEP - Revision 4

[Greg Ewing]

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