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@.

Reply via email to