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
|