Stackless Python for Python 3.0 and Python 3.0.1, now available.

http://zope.stackless.com/Members/rmtew/News%20Archive/3.0

by arem • 17 years ago

28 14 17 years ago

zope.stackless.com

ggruschow• 17 years ago

That's cool and all, but cores are practically growing on trees now. Is there something out there that'll let me efficiently do tons of active objects (coroutines with data that can make sync or async calls?) but scale out across processors and machines (hi EC2, I love you) also? I can do without shared data.

As it stands now, unless I had a big need for bazillions of contexts, I wouldn't touch stackless because I've already got to use other mechanisms to get work running on a lot of different cores / machines at once anyway. Since I'm already doing that, it's nicer to stick to the one mechanism and design things to work within it (keep contexts <1,000).

nihilocrat• 17 years ago

The idea is that Stackless allows you to easily get concurrency via coroutines and message passing. My understanding is that, along with some other things, it's basically Python with no C stack and no Global Interpreter Lock.

It sounds like you already have a method you're comfortable with, so there's obviously not much reason to look for something else unless you are tearing your hair out with your current solution.

bendotc3• 17 years ago

This ends up needing to be posted in every Stackless discussion:

Stackless DOES NOTHING ABOUT THE GIL! Stackless is not about concurrency. It's about implementing coroutines.

It's a really easy mistake to make. Lots of people think Stackless threadlets look like Erlang processes, but instead, they look more like regular Python generators (although they're admittedly much cooler). To complicate matters, people sometimes actually do use the fact that you can pickle threadlets, send them across the wire, and resume them on another thread/process/machine to implement some form of concurrency, but this does not mean that Stackless gets around the GIL in any way vanilla CPython can't.

To explain more about Stackless, I'll refer you to Jesse Noller's recent post on the subject: http://jessenoller.com/2009/02/23/stackless-you-got-your-cor...

dfj225• 17 years ago

What about the multiprocessing module, that has been included with Python since v 2.6?

http://docs.python.org/library/multiprocessing.html

rbanffy• 17 years ago

Won't let programs share a single in-process object the way proper threading support would.

tdavis• 17 years ago

pp (parallel python) supports a pool of machines for handling parallel tasks. She's a bit rough around the edges, but can generally get the job done.

moe• 17 years ago

I hear you, I'd love to have the same thing.

Still the big deal about co-routines for me is not mainly raw performance (or core-utilization) but rather the programming model. I've literally slashed the LOC-count in half for some of our projects just by moving to co-routines, that's what I call a productivity boost.

Also I find myself enjoying co-routines much more than the tangled mess of callbacks and data-locality issues in the multithreaded world.

MaysonL• 17 years ago

I still remember with fondness the first coroutines I wrote, almost 35 years ago: it seemed like a really cool hack to connect a producer of bytes to a consumer of them (both already written, just 6 lines of assembler plus a little bit of init code).

Stackless Python for Python 3.0 and Python 3.0.1, now available.

Related Stories