Stackless Python for Python 3.0 and Python 3.0.1, now available.
zope.stackless.com
Stackless Python for Python 3.0 and Python 3.0.1, now available.
1–10 of 15 posts
Re: Stackless Python for Python 3.0 and Python 3.0.1, now available.
#2That'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).
Re: Stackless Python for Python 3.0 and Python 3.0.1, now available.
#3That'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…
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.
Re: Stackless Python for Python 3.0 and Python 3.0.1, now available.
#4That'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…
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.
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...
Re: Stackless Python for Python 3.0 and Python 3.0.1, now available.
#5That'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…
What about the multiprocessing module, that has been included with Python since v 2.6?
Re: Stackless Python for Python 3.0 and Python 3.0.1, now available.
#6Earlier quoted context omitted.
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.
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 sometim…
Man as a mostly-outside-admirer of Python, I love its terminology: "pickle threadlets". Delicious!
Re: Stackless Python for Python 3.0 and Python 3.0.1, now available.
#7Earlier quoted context omitted.
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.
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 sometim…
Coroutines are concurrent. They are not parallel.
Re: Stackless Python for Python 3.0 and Python 3.0.1, now available.
#8That'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…
What about the multiprocessing module, that has been included with Python since v 2.6? http://docs.python.org/library/multiprocessing.html
Won't let programs share a single in-process object the way proper threading support would.
Re: Stackless Python for Python 3.0 and Python 3.0.1, now available.
#9That'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…
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.
Re: Stackless Python for Python 3.0 and Python 3.0.1, now available.
#10Earlier quoted context omitted.
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 sometim…
Coroutines are concurrent. They are not parallel.
That's a distinction without a (widely accepted) difference. Coroutines exist at the same time as one another (you could say they exist in parallel or concurrently), but they do not execute at the same time within a single process (1). I think most people wouldn't call it either parallel or concurrent, but if concurrency means something else to you, that's fine, but don't correct me by your definition.
For what it's worth, here's the intro to "Concurrency (computer science)" on Wikipedia:
"In computer science, concurrency is a property of systems in which several computations are executing simultaneously, and potentially interacting with each other. The computations may be executing on multiple cores in the same chip, preemptively time-shared threads on the same processor, or executed on physically separated processors. A number of mathematical models have been developed for general concurrent computation including Petri nets, process calculi, the synchronous model and the Actor model."
(1) Okay, so, they could be operating at the same time if two tasklets are in different threads and at least one is inside C code that has released the GIL. But that's the same as any CPython code.