[Python-Dev] Re: [Stackless] comments on PEP 219

Gordon McMillan gmcm@hypernet.com
Tue, 13 Mar 2001 15:02:14 -0500


Can we please get the followups under control? Bernd sent 
me a private email. I replied privately. Then he forwarded to 
Stackless. So I forwarded my reply to Stackless. Now Jeremy 
adds python-dev to the mix.

> >>>>> "BR" == Bernd Rinn <Bernd.Rinn@epost.de> writes:
> 
>   BR> On Tue, Mar 13, 2001 at 12:17:39PM -0500, Gordon McMillan
>   wrote: >> The one instance I can find on the Stackless list (of
>   attempting >> to use a continuation across interpreter
>   invocations) was a call >> the uthread.wait() in __init__.
>   Arguably a (minor) nuisance, >> arguably bad coding practice
>   (even if it worked).
> 
> [explanation of code practice that lead to error omitted]
> 
>   BR> So I suspect that you might end up with a rule of thumb:
> 
>   BR> """ Don't use classes and libraries that use classes when
>   doing BR> IO in microthreaded programs!  """
> 
>   BR> which might indeed be a problem. Am I overlooking something
>   BR> fundamental here?

Synopsis of my reply: this is more a problem with uthreads 
than coroutines. In any (real) thread, you're limited to dealing 
with one non-blocking IO technique (eg, select) without going 
into a busy loop. If you're dedicating a (real) thread to select, it 
makes more sense to use coroutines than uthreads.

> A few other variations on the question come to mind:
> 
>     If a programmer uses a library implement via coroutines, can
>     she call library methods from an __xxx__ method?

Certain situations won't work, but you knew that.
 
>     Can coroutines or microthreads co-exist with callbacks
>     invoked by C extensions? 

Again, in certain situations it won't work. Again, you knew that.
 
>     Can a program do any microthread IO in an __call__ method?

Considering you know the answer to that one too, you could've 
phrased it as a parsable question.
 
> If any of these are the sort "in theory" problems that the PEP
> alludes to, then we need a full spec for what is and is not
> allowed.  It doesn't make sense to tell programmers to follow
> unspecified "reasonable" programming practices.

That's easy. In a nested invocation of the Python interpreter, 
you can't use a coroutine created in an outer interpreter. 

In the Python 2 documentation, there are 6 caveats listed in 
the thread module. That's a couple order of magnitudes 
different from the actual number of ways you can screw up 
using the thread module.

- Gordon