quetz-mod_python-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jim Gallacher <jg.li...@sympatico.ca>
Subject Re: FileSession.py - improved? version
Date Mon, 11 Apr 2005 16:35:17 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) ?
> 
> Regards,
> Nicolas
> 

Hi Nicolas,

Attached is a new version of FileSession.py that uses a different 
locking scheme. In a "well duh" kind of moment I thought why not just 
check if the session is locked before trying to lock the file? It seems 
to work so I've changed the default locking back on.

class FileSession(BaseSession):
     def lock_file(self):
         if not self._locked:
             self._req.log_error('lock file %s' % self._sid)
             _apache._global_lock(self._req.server, self._sid)
             self._locked = 1

     def unlock_file(self):
         if self._locked and not self._lock:
             self._req.log_error('unlock file %s' % self._sid)
             _apache._global_unlock(self._req.server, self._sid)
             self._locked = 0

    # pseudo code to demonstrate
    def do_test(self):
        self.lock_file()
        try:
            do_file_read_or_write_stuff()
        finally:
            self.unlock_file()

Tested with and without session locking and have not seen any problems 
so far:
ab -n 500000 http://localhost/session_test.py

Regards,
Jim

Mime
View raw message