hi lawrence.. 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... thanks.... -----Original Message----- From: python-list-bounces+bedouglas=earthlink....@python.org [mailto:python-list-bounces+bedouglas=earthlink....@python.org]on Behalf Of Lawrence D'Oliveiro Sent: Monday, March 02, 2009 12:29 AM To: python-list@python.org Subject: RE: file locking... In message <mailman.1004.1235929208.11746.python-l...@python.org>, bruce wrote: > 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 > time... 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. -- http://mail.python.org/mailman/listinfo/python-list -- http://mail.python.org/mailman/listinfo/python-list
