The Future of Python Threading

[Justin T.]

On Aug 10, 3:52 am, Jean-Paul Calderone <exar... at divmod.com> wrote:
> On Fri, 10 Aug 2007 10:01:51 -0000, "Justin T." <jmtull... at gmail.com> wrote:
> >Hello,
>
> >While I don't pretend to be an authority on the subject, a few days of
> >research has lead me to believe that a discussion needs to be started
> >(or continued) on the state and direction of multi-threading python.
>
> > [snip - threading in Python doesn't exploit hardware level parallelism
> >  well, we should incorporate stackless and remove the GIL to fix this]
>
> I think you have a misunderstanding of what greenlets are.  Greenlets are
> essentially a non-preemptive user-space threading mechanism.  They do not
> allow hardware level parallelism to be exploited.

I'm not an expert, but I understand that much. What greenlets do is
force the programmer to think about concurrent programming. It doesn't
force them to think about real threads, which is good, because a
computer should take care of that for you.Greenlets are nice because
they can run concurrently, but they don't have to. This means you can
safely divide them up among many threads. You could not safely do this
with just any old python program.

>
> >There has been much discussion on this in the past [2]. Those
> >discussions, I feel, were premature. Now that stackless is mature (and
> >continuation free!), Py3k is in full swing, and parallel programming
> >has been fully realized as THE next big problem for computer science,
> >the time is ripe for discussing how we will approach multi-threading
> >in the future.
>
> Many of the discussions rehash the same issues as previous ones.  Many
> of them are started based on false assumptions or are discussions between
> people who don't have a firm grasp of the relevant issues.

That's true, but there are actually a lot of good ideas in there as
well.

>
> I don't intend to suggest that no improvements can be made in this area of
> Python interpreter development, but it is a complex issue and cheerleading
> will only advance the cause so far.  At some point, someone needs to write
> some code.  Stackless is great, but it's not the code that will solve this
> problem.
Why not? It doesn't solve it on its own, but its a pretty good start
towards something that could.