[Python-Dev] Free threading

[Paul Prescod]

Guido van Rossum wrote:
> 
>...
> 
> Anyway, I don't see the point: if you want two 100% independent
> interpreters, you can get that easily by forking two separate
> processes.  That's what separate processes are *for*...

I am 95% in agreement with you and that's what I told the Perl guys.
That's why I see their "ithreads" solution as a little weird. But the
other 5% is when you are running in an already-threaded environment and
it is only the Python stuff that you want to be separate (for
performance). e.g. Apache, IIS, Sendmail, COM etc.

Also, Windows doesn't have "fork" so spawning a process means actually
running an executable from disk AFAIK. That's somewhat inefficient. But
I'll repeat that in the big picture I agree with you. The combination of
shared-data threads and independent-data processes is good enough for
most real-world apps.

>...
> I bet the level of sharing exposed here can be implemented easily on
> top of the mmap module.

Please excuse my ignorance: how do you do locking in an mmap solution?

>...
> That sounds to me a quicker road to an efficient SMP solution than
> trying to get rid of the GIL.

That's why I mentioned it. For whatever reason, the GIL project seems to
only be doable by Greg S. (or he's the only one with interest?) so I
thought a new approach might catch someone's interest.

Does your mild statement of approval indicate that you see the benefit
of having independent in-process interpreters? Or are you still thinking
about using real processes? If the former, it still seems that the
interpreter itself needs a little work so that it is safely reentrant in
the sense of any other C library. There especially needs to be a way to
NOT share a GIL and NOT share any other mutable data.

If you are talking about real processes, then "all" that's needed is an
efficient RPC mechanism.
-- 
Take a recipe. Leave a recipe.  
Python Cookbook!  http://www.ActiveState.com/pythoncookbook