[mod_python] Using _global_lock in scripts

Jim Gallacher jpg at jgassociates.ca
Fri Apr 7 16:26:28 EDT 2006


Phil Groce wrote:
> I have a resource which my module will need to access, potentially
> from multiple child processes, since I can't directly control the MPM
> being used. The logical implementation is to persist the resource to
> disk and lock access with a mutex, similarly to what the Session
> module does.
> 
> Session, of course, does this with _apache._global_lock and
> _apache._global_unlock do. However, their names and the names of the
> module seem to indicate that the implementors intend for them to be
> private.

They are there to support session locking. You will have a possible 
conflict if you are using sessions and want to "borrow" a lock for other 
purposes.

> So I have a few questions:
> 
> 1. Despite my misgivings at using private interfaces, it would
> simplify my life greatly if I could use these functions. Is it
> reasonable to assume that, even if they are private, they will exist
> and have pretty much the same contract for a while yet? (The seem to
> have existed, largely unchanged, for quite a while now.)

The locks are actually used for 2 separate purposes: Session locking and 
serializing access to the dbm file for DbmSession. Lock index 0 is 
reserved for accessing the dbm file. Locks 1 to MAX_LOCKS are used for 
locking the actual sessions, where the lock index is derived from a hash 
of the session id.

As long as  you don't use DbmSession you can safely use lock index 0. eg.

_apache._global_lock(server, None, 0)

Note that you'll still be able to use FileSession, since it does use 
index 0.

I think you can assume that this interface will not change in the near 
future. When I was working on FileSession there was quite a bit of 
discussion on alternative locking mechanisms, but even if the 
implementation is changed in the future to improve performance I can't 
imagine why the interface would change.

> 2. If it is not reasonable, what suggestions do you have for
> implementing concurrent access to a resource from (potentially)
> multiple interpreters and/or child processes?

You could always use a filelock. Not the most efficient way to do it, 
but it would work. See portalocker.py for ideas.
http://aspn.activestate.com/ASPN/Cookbook/Python/Recipe/65203

> 3. If it _is_ reasonable....any chance that this can become a
> documented mod_python feature? :)

Hmmm... I think it's a little too much of a hack to go in the offical 
documentation - bit too much like handing someone a loaded gun.

Jim


More information about the Mod_python mailing list