Thanks for this input.  Your comments here turned out to be dead on.  The
problem is the GIL.

We are currently running Sybase databases using the python Sybase-0.37
module for data access.

This module will set the GIL.  So if the query takes any time at all, every
other session will freeze.  It does release it when the connection is
closed, but if the query takes awhile it effectively denies service to every
other session.

I am just learning about this, but my initial inquiries suggest that the
only way to achieve true concurrency using a language like python is to
launch multiple interpreters.

I don't yet have the solution to my problem, but at least now I know what
the problem is, and that is half the battle.

Thanks again, and thanks to everyone's input, it has helped immensely.

Jon Emmons

-----Original Message-----
From: Dieter Maurer [mailto:[EMAIL PROTECTED] 
Sent: Wednesday, May 28, 2008 2:27 PM
To: Jon Emmons
Subject: Re: [Zope] Multithreading sessions

Jon Emmons wrote at 2008-5-23 08:58 -0400:
> ...
>I am running zope 2.9.4 and have observed that it will not simultaneously
>serve pages to my users.

Usually, it does.

I have seen database adapter packages (an old "psycopg" version, to be
precise) that forgot to release the GIL for some operations.
Then Zope freezes while these operations are executed.

A surprising report of a similar kind was: while Zope's embedded
profiler is in use, Zope effectively runs in single thread mode (such
that other threads do not distort the timing results).
Probably not your problem ... but who knows.

Further potential reasons (for almost surely not responsible for your
current problem:

  Expensive operations implemented in "C" (such as operations on huge

  Creating excessive amounts of objects (causing lots
  of generation 2 garbage collections which hold the GIL)


Zope maillist  -
**   No cross posts or HTML encoding!  **
(Related lists - )

Reply via email to