GIL in the new glossary

[дамјан г.]

> This has come up lots of times, and you can find some old threads (of
> the c.l.py kind, not the posix kind :-)).  But in general, the strategy
> is to use some form of IPC, and launch many Python processes.  Each
> Python iterpreter can get run in its own processor, and partial
> calculations/results exchanged as needed.  Various libraries help you
> support this.
> 
> Admittedly, this is not the absolutely most memory/CPU friendly
> technique possible... but then, Python isn't to start with.  If you
> really need to scrape out every last CPU cycle, use C, OCaml, Fortran,
> or assembly.

But who would like to use those?? :)

Seriously, the biggest problem with GIL is in applications like mod_python,
which is an Python extension to Apache. When Apache works in the
multithreaded MPM (I think it was called "Worker") the GIL starts to be a
serious bottleneck in your server performance. The GIL will lock your
Apache threads if they happen to hit on a mod_python handled location.




-- 
Дамјан                                  (jabberID:damjan at bagra.net.mk)

           Intel: where Quality is job number 0.9998782345!