Developers of Sympa

[David Verdin <address@concealed>]

Hi Soji,

It's great you investigated this problem. We will need correct and efficient lock badly if we want to share spools between several Sympa instances on separate servers.

Le 23/07/13 17:43, IKEDA, Soji a écrit :

On Thu, 16 May 2013 10:23:41 +0900
I wrote:

However, currently Lock::lock() locks _lock file_, not the file
passed to Lock::new(). So lock files can not be removed as long as
any processes are running.

Is this behavior unnecessary, isn't it?

It is necessary, because "forward locking" (locking files even if it does not
exist, I don't know what to call it officially though) is required.

flock(2) can not perform forward locking.  That seems why current behavior of
Sympa::Lock is --- locking lock files instead of target files themselves.

It looks like you found the correct reason. i didnt' write this part of the code so it remained a little bit obscure to me.

File::NFSLock can perform forward locking.

So I propose that File::NFSLock should be solely used and that flock(2) should
not be used anymore.

that means that we should not even bother to know whether the spools, for example, are on an NFS volume or not?
is that does not cripple performances, I gladly approve this project. It is worth a try anyway.

I assume that File::NFSLock works on any Unix-like environments.  Is this
assumption true? (File::NFSLock uses "hardlink magic").

Good question. It is hard to verufy but, if we consider that NFS is widely supported and that hardlink magic is necessary to make it work, we can asume that the module will be supported on most Unix-like OS.
The question now is: what is "hardlink magic"? Do you mean: the principle of hardlinks that allow a file to existe apparently at exactly the same number of hardlinks that point to its memory location and, subsequently, to disappear only when the last of these hardlink is removed. If yes, I think this a very well known behaviour and works probably everywhere. If it is another mechanism, then I's like to understand what it is...

Anyawy, we should investigate this. Right now Étienne and I are still haed first in the merge so I don't think we'll be able to search a lot.

Cheers,

David

Regards,

--- Soji

--
A bug in Sympa? Quick! To the bug tracker!

David Verdin Infrastructure pour les Services Informatiques
Tél : +33 2 23 23 69 71 Fax : +33 2 23 23 71 21   www.renater.fr	RENATER 263 Avenue du Gal Leclerc 35042 Rennes Cedex

Attachment: smime.p7s
Description: Signature cryptographique S/MIME