Developers of Sympa

[David Verdin <address@concealed>]

Le 23/07/13 18:40, IKEDA Soji a écrit :

David, sorry for disturbing your work.  My proposal can be
discussed later.

You don't disturb anything. I just wanted to say that we can't do much more than merging right now; I'm more than happy to see you and Guillaume tackle this kind of problems that we need to solve anyway.

A few comment to memorize this issue:

On Tue, 23 Jul 2013 17:55:40 +0200
David Verdin <address@concealed> wrote:

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

"Hardlink magic" (I named it) is, as I understood:
(1) There may be only one main lock file (i-node) by each target
  file;
(2) Each proccess or routine creates a hardlink to the file above
  so that add shared-lock to the target file, and unlink it to
  unlock target file;
(3) When the main lock file does not have hardlinks anymore,
  it is removed from filesystem by the kernel.

- Lock file will be removed by kernel automatically.
- As lock files may exist independent from target files, forward
  locking is possible.
- As hardlink is usual thing on Unix-like systems, it may work
  on environmets not limited to NFS.

OK, so that's what I understood.
This looks perfect to me.

Regards,

--- Soji

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! 
<https://sourcesup.renater.fr/tracker/?group_id=23>
RENATER logo
*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 <http;//www.renater.fr>
	RENATER
263 Avenue du Gal Leclerc
35042 Rennes Cedex

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