[Chicago] Stackless

[Pete]

On Tuesday June 5 2007 2:21 pm, Atul Varma wrote:
> On 6/5/07, Chris McAvoy <chris.mcavoy at gmail.com> wrote:
> > This Stackless tutorial has a blurb about "concurrency is the new
> > thing"
> > http://members.verizon.net/olsongt/stackless/why_stackless.html#concurren
> >cy-might-just-might-be-the-next-big-programming-paradigm which I agree
> > with...however...if you make a bunch of microthreads in
> > Stackless...they're not going to take advantage of multiple cores or
> > cpu's, right?  Or am I wrong about that?
>
> I believe you are correct.  From what I understand, a lot of people

Yup.  Stackless doesn't get rid of the GIL - only one thread can be in Python 
code at a time.  For GIL-less alternatives, please see your local Jython or 
IronPython dealer.

> The bottom line, though, is that it appears as though Python isn't
> really going to improve its support for threads; rather, the
> assumption is that if a Python solution needs to take advantage of
> multiple processors, it should use multiple processes instead of
> multiple threads.

Threads aren't inherently evil.  Threads + shared mutable state is a bit of a 
recipe for disaster.

Queues help: http://docs.python.org/lib/QueueObjects.html
Don't leave  your MainThread without one.

Threads in Python are good when you have a Fast Shiny C Library that releases 
the GIl and you want to run it on a multi-core box.

All that said, a nice protocol for inter-process (or box) message passing 
(*not* shared state, thank you very much SOAP/WS-*/RPC) would certainly be 
desirable & make writing multi-process apps easier than multi-threaded ones.

-- 
Peter Fein   ||   773-575-0694   ||   pfein at pobox.com
http://www.pobox.com/~pfein/   ||   PGP: 0xCCF6AE6B
irc: pfein at freenode.net   ||   jabber: peter.fein at gmail.com