I would think the GIL is relevant per process and not the whole system.That said , since ZEO ends up doing multiple python interpreters its possibly the more reliable approach to take advantage of SMP linux.
please point out any flaws in my thought process .....
SMP is not doing any good for you when not running multiple Python processes. The GIL doesn't work per CPU but for the whole system. You very likely will end up locking your CPUs 2-n on a N-way system due to the GIL.
If I ran multiple python processes on a N-way system they would not deadlock on the GIL as they dont contend for the same GIL.
ZEO actually does the trick, but you should use CPU binding for the processes to make sure they won't affect other processors.
What about threads on linux ? will binding a process to a CPU also mean all threads spawned by the process are also bound to the same processor ? I am not aware of linux support for binding threads to a CPU so I guess it does not matter .
Further if extension modules such as RDBMS adapters do not cause the GIL to be freed up ,If I understand tim correctly any calls to only "known" thread safe APIS will cause the GIL to be unlocked. So python applications using thread safe implementations of MySQL db api will still suffer from the GIL bottleneck. bummer. time to deploy ZEO or hack the db adapter to be GIL aware ? I wonder if there is a way to inform python about thread safe api calls so that it can release the GIL
thanks much for this discussion regards sathya
Zope-Dev maillist - [EMAIL PROTECTED]
** No cross posts or HTML encoding! **
(Related lists - http://mail.zope.org/mailman/listinfo/zope-announce