| From: | Pawel Jakub Dawidek <nick@xxxxxxxxxxxxxxxxx> |
| Date: | Wed, 3 Sep 2003 14:21:46 +0200 |
On Wed, Sep 03, 2003 at 12:20:42AM -0700, Matthew Dillon wrote: +> :But I see one potential problem. +> : +> :In directory 'a' you've file 'b', and directory 'c' is empty. +> : +> : thread 1 thread 2 +> : +> : lock b +> : lock d +> : remove c (is empty, so this can be done) +> : rename b to d +> +> Ah. I think this issue can be dealt with by observing that the +> attempt to remove C will call cache_purge(C), which will then block +> waiting on D's lock. i.e. it will not be able to purge C's namecache's +> children until the rename operation is complete, and then it will notice +> that the directory is not empty. I think the case only occurs when +> one actually attempts to remove C. You've wrote that "The one representing "d" will be a negative cache entry, placemarking the operation.". So maybe this negative entry could be treated as file in directory. In other words 'lock d' will create some shade object in 'c' directory (in namecache) and this will prevent removing 'c'. Or whatever... -- Pawel Jakub Dawidek pawel@xxxxxxxxxxx UNIX Systems Programmer/Administrator http://garage.freebsd.pl Am I Evil? Yes, I Am! http://cerber.sourceforge.net
Attachment:
pgp00002.pgp
Description: PGP signature