|
Jim Gallacher
jpg at jgassociates.ca
Fri Apr 7 17:43:37 EDT 2006
Oops, I missed the use of _apache._global_lock(server, None, 0) in the psp dbm cache. You could run into problems if you are using psp at the same time as your resource. If you want to use the lock and and psp in the same request you'll need to be careful how you arrange your code. Jim Jim Gallacher wrote: > 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 > _______________________________________________ > Mod_python mailing list > Mod_python at modpython.org > http://mailman.modpython.org/mailman/listinfo/mod_python >
|