From: Takahiro Kambe <taca@...>
Date: 2002-09-28T01:20:58+09:00
Subject: [ruby-dev:18404] Re: pstore.rb can make a broken store

In message <hvoelbfct4j.fsf@coulee.a02.aist.go.jp>
	on Sat, 28 Sep 2002 01:09:40 +0900,
	Tanaka Akira <akr@m17n.org> wrote:
> > fcntl lockって、dupしたファイル記述子が残っていても、ロックかけたファ
> > イル記述子をcloseしたらロックが外れるだったか、子プロセスに引き継げな
> > いとか「壊れた仕様」と聞いたことがあります。
> 
> この話のソースを教えていただけないでしょうか。
古くはINNか何かのメーリングリストだったと思いましたが、NetBSD(に限らな
いと思いますが)のfcntl(2)にありました。

     This interface follows the completely stupid semantics of AT&T System V
     UNIX and IEEE Std 1003.1-1988 (``POSIX'') that require that all locks as-
     sociated with a file for a given process are removed when any file de-
     scriptor for that file is closed by that process.  This semantic means
     that applications must be aware of any files that a subroutine library
     may access.  For example if an application for updating the password file
     ...
     database.  Another minor semantic problem with this interface is that
     locks are not inherited by a child process created using the fork(2)
     function.  The flock(2) interface has much more rational last close se-
     mantics and allows locks to be inherited by child processes.  Calling
     flock(2) is recommended for applications that want to ensure the integri-
     ty of their locks when using library routines or wish to pass locks to
     their children.  Note that flock(2) and fcntl(2) locks may be safely used
     concurrently.

flock(2)の方には、

NOTES
     Locks are on files, not file descriptors.  That is, file descriptors du-
     plicated through dup(2) or fork(2) do not result in multiple instances of
     a lock, but rather multiple references to a single lock.  If a process
     holding a lock on a file forks and the child explicitly unlocks the file,
     the parent will lose its lock.

といった記述もあります。ファイルをunlink(2)する場合は、最後にオープン
されていたファイル記述子がcloseされた時点で実体が消えることと対比する
と、極めて不自然に思えます。

> 思うに、lock は fork しても受け継げないので、3つのテーブルのうち file
flock(2)は受け継げます。

-- 
神戸 隆博 / Takahiro Kambe