(Fwd) Re: [Stackless] comments on PEP 219

[Gordon McMillan]

Hmmm, I see Bernd forwarded his message, so I guess I need 
to forward my reply...


Bernd,

This is, I think, more a problem with uthreads than stackless. 
My SelectDispatcher is designed precisely for doing non- 
blocking IO. Whenever something happens on the socket, a 
coroutine (very thread like) is awakened and goes about it's 
business. It doesn't relinquish control until it wants to.  

uthreads complicate things because the control transfers 
aren't voluntary. It's my impression that at least most people 
are using uthreads simply because they can write code 
according to a familiar model. I think many of them would do 
better to adopt a coroutine model.  

[Now Stackless is not going to solve the problem of using 2 
incompatible non-blocking IO mechanisms without going into 
a busy loop. You need real threads for that. All Stackless lets 
me do is rearrange the code so, for example, I don't need a 
state machine / notifiers to multiplex sockets.]  

So your comments are true, but the lesson I would draw is 
"don't use uthreads, use coroutines". With coroutines, you 
know when control is getting transfered, so you know when 
you can use libraries / magic methods and when you can't.

[When I said "(arguably) bad coding practice", I was referring to
uthread.wait() in an __init__. I would regard this as bad
practice using real threads; or indeed, anything time dependent
or that involved control transfers in an __init__.]

- Gordon

> 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).
> 
> I think that you are talking about the piece of code I sent to
> the list when I got the "attempt to run a locked frame"
> exception for the first time. I am not completely sure what you
> mean with "bad coding practice". I assume you mean that it can
> (and should) be avoided easily. However, IMHO you will almost
> for sure get into this kind of trouble when trying to do
> non-blocking IO operations in magic methods (which I think is a
> relevant case). This kind of non-blocking IO calls (i.e. calls
> to a non-blocking select) can be hidden very well in libary
> functions. When the systems built on microthreads are getting
> more and more complex, they almost for sure will be hidden in
> library functions that are called by other library functions...
> 
> So I suspect that you might end up with a rule of thumb:
> 
> """
> Don't use classes and libraries that use classes when doing IO
> in microthreaded programs! """
> 
> which might indeed be a problem. Am I overlooking something
> fundamental here?
> 
> Regards,
> 
> Bernd
> 
> -- 
> Bernd Rinn
> Fakultät für Physik
> Universität Konstanz
> 
> Tel. 07531/88-3812, 
> e-mail: Bernd.Rinn at uni-konstanz.de
> PGP-Fingerprint: 1F AC 31 64 FF EF A9 67  6E 0D 4C 26 0B E7 ED
> 5C


------- End of forwarded message -------

- Gordon
_______________________________________________
Stackless mailing list
Stackless at starship.python.net
http://starship.python.net/mailman/listinfo/stackless