bedouglas at earthlink.net
Mon Mar 2 12:15:06 CET 2009
my concern about a "gatekeeper" wasn't so much related to performance, as
the possibility of race conditions... if you only have a few client apps
trying to access the files in the target dir, than you can in theory
probably be ok..
for my app, the client process seeking files in the dir are client processes
hitting a web service. i don't want these guys to be in a potential "wait"
state, which could happen if i had the back end app simply do a try and hope
for the best on the lock file.
what i believe i'm ultimately going to need, is some form of a queuing
system, where the client app, via a backend webservice/process, puts in a
queue/order saying it's ready for a batch of files.. and have this fifo
process somehow gets the files ready for processing for the client...
From: python-list-bounces+bedouglas=earthlink.net at python.org
[mailto:python-list-bounces+bedouglas=earthlink.net at python.org]On Behalf
Of Lawrence D'Oliveiro
Sent: Monday, March 02, 2009 12:29 AM
To: python-list at python.org
Subject: RE: file locking...
In message <mailman.1004.1235929208.11746.python-list at python.org>, bruce
> using any kind of file locking process requires that i essentially have a
> gatekeeper, allowing a single process to enter, access the files at a
The gatekeeper doesn't need to do any more than ensure that any particular
filename is only locked by a maximum of one process at a time.
Given that interprocess communication (and consequent context-switching) is
going to be orders of magnitude faster than accessing disk files, there's no
a-priori reason to assume that this need be a performance bottleneck.
More information about the Python-list