quetz-mod_python-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From David Fraser <dav...@sjsoft.com>
Subject Re: FileSession.py - improved? version
Date Mon, 11 Apr 2005 12:31:25 GMT
Nicolas Lehuen wrote:

>OK, I've checked your code in, but I have a remark : the number of
>global locks is limited in  mod_python. That's why you have something
>like "mod_python: Creating 32 session mutexes based on 0 max processes
>and 250 max threads." in the error.log file.
>
>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. What I fear is that those collisions are deadlock-prone...
>
>In that case, I wonder if it is worthy to have two different locking
>mechanisms (at the session level and a the file level) since it will
>make collisions even more probable. You solve this by disabling
>session locking by default, but session locking can truly be useful
>(for example, when you have a site which loads a frameset in which
>each frame requires a session).
>
>I think we should find a way to have reentrant session locking, so
>that if a process/thread already holds a session lock, a new call to
>BaseSession.lock() does not block the process/thread. This way, we
>could simply enable session locking by default and re-use the same
>locks for file-level locking. This would enable to have file-level
>locking even if session-level locking is disabled, while keeping the
>number of locks (and lock collisions) low.
>
>Or, we could try to re-evaluate the need for this finite global lock
>pool. I guess Grisha implemented this for the sake of performance
>(apparently global mutexes can be expensive in some implementations of
>the APR). Why not create a distinct lock for each lock name (and thus
>exceed the 32 limit) ?
>  
>
Even if the 32 lock limit is required, it may be possible to use the 
global locks to access other locks that are not global in the same way.
For example, if you have 32 global mutexes, you can use each one to 
control access to an area of shared memory that is not individually 
locked, but contains multiple lock states. So the granularity of the 
locking is larger, but you can still lock / unlock individual sessions.

Not sure if I've desccribed that in a way that makes any sense or would 
be helpful, but anyway...

David

Mime
View raw message