Hi There, Thanks for setting up my space :-). I think I'm ready to upload, I just wish to deliberate with you guys on the naming convention of my module. Here is the description: QueLock is a multi-host atomic nfs-safe (ahem) advisory queing locking system. It uses file-based locking to acheive this. It is 95 % fair, meaning that during periods of fast locking, que jumping can occur. This is a resource locking scheme, not just for locking files/directories. So it doesn't matter if your trying to lock a file or directory - the idea is the same. The queing system is essentially the key to this system, as I've found in the past I've wanted to coordinate several scripts all editing the same files and been unable to do this due to the lack of locking system which can do this. I've basically had to coordinate what this module does, into each script - so moving the class into a module seemed like a reasonable idea. The only other option close to this which is nfs safe is IPC::Locker, however this is daemonic, which I wanted to avoid ... and it doesn't support queing. DLSI: IPC::QueLock adpO An nfs-safe advisory queing locking system KBARBER I'd like to use IPC::QueLock because IPC is the closest high-level system I can see which has something to do with Locks over nfs in this manner. LockFile::QueLock is another type of though of, although again this is a resource locking system - so "Lock_File_" is a little misleading. Anyways, what are your thoughts? ken@.
