Dario Lopez-Kästen wrote:
thanks much for the info.
turns out that the updated kernel rpms for RH8 and RH 9 2.4.20-28.8smp
contain the patch for cpu affinity as well
at this point seems like a good idea to deploy ZEO and bind each client
to a processor and test it out ,hopefully with a 4way sm
sathya wrote:
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 .
For a full discussion of this and oter SMP
[christian]
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
On Wed, 2004-04-28 at 03:41, sathya wrote:
> [sathya]
> great ! If I understand correctly, if we had a zope process running on
> an smp linux machine and doing lots of RDBMS calls we would not be
> limited by the GIL. In essence threads running on multiple cpus would
> probably not have to wait
Tim Peters wrote:
tim thanks much for the explanation. some points below.
[sathya]
I read somewhere that each zope thread acquires the global python
interpreter lock before processing a request and until it releases it
the other zope threads are essentially locked out.
[tim]
No. The GIL effecti
[sathya]
> I read somewhere that each zope thread acquires the global python
> interpreter lock before processing a request and until it releases it
> the other zope threads are essentially locked out.
The Python GIL (global interpreter lock) affects all code written in Python:
only one thread at
