quetz-mod_python-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Gregory (Grisha) Trubetskoy" <gri...@apache.org>
Subject Re: FileSession.py - improved? version
Date Mon, 11 Apr 2005 14:31:45 GMT

On Mon, 11 Apr 2005, Nicolas Lehuen wrote:

> By having a look at _global_lock and _global_unlock in _apachemodule.c, 
> you will see that any request for a lock will be brought down to one of 
> the N-1 (here 32 - 1 = 31) pre-allocated global locks (the -1 stands for 
> the lock 0 which is special, see the code). Hence, with more than 31 
> concurrent requests, you WILL have collisions.

Yes. If you search the mailing list archives from long-long ago (don't 
know if they're available online), there should be a thread on the logic 
behind it. The main idea is that apache only processes as many concurrent 
requests as there are threads/processes available, therefore having as 
many locks as there are sessions is a waste, you only need no more than 
apache can process.

On top of that consider that only a fraction of requests are session 
requests - images and other static files shoudn't be session based.

So what seems like a big problem at first, isn't really. You _will_ have 
collisions with this scheme, but all that it does is make one session wait 
for another. The probablilty of this happening is relatively low, and this 
seems like a nice compromise.

Also, all this is relevant if session locks are important to you. They're 
on by default, bu if you're _really_ concerned with performance you should 
consider having them off.

On some OS's (namely certain popular variations of RedHat) the lock of 
choice picked by APR is the SysV semaphore. There is a finite number of 
them and if not released properly you will get "no space left on device" 
when trying to allocate a lock. If you look at the Fedora mod_python RPM, 
you'll see that they set MAX_LOCKS in mod_python.h from 32 to 4, and 
that's actually not an unreasonable option IMO.

> What I fear is that those collisions are deadlock-prone...

A dead-lock is a BUG. There are no dead-locks in the current session 
implementation to the best of my knowledge, we just need to make sure same 
is true for FileSession :-).


View raw message