Tim Peters wrote: tim thanks much for the explanation. some points below.
[sathya][tim]
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.
[sathya]No. The GIL effectively serializes threads doing pure computation in Python, but many pieces of the Python implementation release the GIL around calls to known-threadsafe C libraries. The most important examples of that are I/O, of many kinds. For example, if a Python thread opens a socket, the GIL is released around the C-level code that does the low-level socket open, which allows other Python threads to proceed in parallel (of course the thread that does the C-level socket open waits for the latter to finish; it reacquires the GIL after the socket operation is complete and it's ready to go back to interpreting Python bytecodes). Because Zope does a lot of network I/O, this form of parallelism can be very useful for it.
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 on acquiring the GIL as most every page request results in a ZSQL method call which in turn would release the GIL. Therefore SMP may not be hindered by the GIL.
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 .....
again thanks very much for putting it in persepective. it clears up some fog for us !
regards sathya
_______________________________________________
Zope-Dev maillist - [EMAIL PROTECTED]
http://mail.zope.org/mailman/listinfo/zope-dev
** No cross posts or HTML encoding! **
(Related lists - http://mail.zope.org/mailman/listinfo/zope-announce
http://mail.zope.org/mailman/listinfo/zope )
