[Python-Dev] Free threading

[Paul Prescod]

Tim Peters wrote:
> 
>...
> 
> Well, I'm not a Tcl guy, but Tcl has historically had no threads at all, yet
> did have an event model where the *illusion* of multiple threads could still
> be put to good use.  I wouldn't fall over dead with surprise if that's all
> there were to it:  Extreme Fear of Threads <wink>.

No, Tcl has real threads now. Tcl and Perl both share a model that the
Perl guys call "Ithreads". (for interpreter threads or independent
threads, I guess) where each interpreter is firewalled from the other
unless you ask to share information. Tcl's threads were driven by the
AOL guys' need to get massive scalability.

>...
> That's cool.  There isn't much code supporting multiple interpreters, so
> there's little to gain by getting rid of it now.  I just wish it were
> *used* -- and that it had a more compelling use case <wink>.

Why do people use mod_python, fcgi, mod_snake, mod_php and all of those
other things instead of pure CGI? The usual claim is that they dislike
the cost of forking a process and loading the interpreter code. Now
imagine a user with a 20 processor machine. She isn't going to be happy
with the price of forking processes and using IPC for information
sharing either. On the other hand, she isn't going to be happy with a
shared GIL.

Free threading helps, but if sharing data has a performance cost (e.g.
by requiring reference count operations to be locked, or requiring
mutexes on dictionaries) then you might not want to pay that cost
either. The Perl guys convinced me of that much.

The most popular "embedded scripting languages" (PHP and VBScript/ASP)
use this totally independent thread model. As far as I know, neither has
a concept of sharing information between threads. To a PHP programmer,
that's what SQL and browser cookies are for. :-)
-- 
Take a recipe. Leave a recipe.  
Python Cookbook!  http://www.ActiveState.com/pythoncookbook