Thread

1. Re: On file locking

   Giles Lean <giles@nemeton.com.au> — 2003-02-02T05:17:22Z

   Curt Sampson <cjs@cynic.net> wrote:
   
   > At any rate, it seems to me highly unlikely that, since the child has
   > the *same* descriptor as the parent had, that the lock would
   > disappear.
   
   It depends on the lock function.  After fork():
   
       o with flock() the lock continues to be held, but will be unlocked
         if any child process explicitly unlocks it
   
       o with fcntl() the lock is not inherited in the child
   
       o with lockf() the standards and manual pages don't say
   
   Boring reference material follows.
   
   flock
   ===== 
   
   From the NetBSD manual page:
   
   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.
   
   The Red Hat Linux 8.0 manual page has similar wording.  (No standards
   to check here -- flock() is not standardised in POSIX, X/Open, Single
   Unix Standard, ...)
   
   fcntl
   =====
   
   The NetBSD manual page notes that these locks are not inherited by
   child processes:
   
        Another minor semantic problem with this interface is that locks
        are not inherited by a child process created using the fork(2)
        function.
   
   Ditto the Single Unix Standard versions 2 and 3.
   
   lockf()
   =======
   
   The standards and manual pages that I've checked don't discuss
   fork() in relation to lockf(), which seems a peculiar ommission
   and makes me suspect that behaviour has varied historically.
   
   In practice I would expect lockf() semantics to be the same as
   fcntl().
   
   Regards,
   
   Giles
     
   
   
   
   
   
   
   
   

2. Re: On file locking

   Tom Lane <tgl@sss.pgh.pa.us> — 2003-02-02T07:31:47Z

   Giles Lean <giles@nemeton.com.au> writes:
   > Boring reference material follows.
   
   Couldn't help noticing that you omitted HPUX ;-)
   
   On HPUX 10.20, flock doesn't seem to exist (hasn't got a man page nor
   any mention in /usr/include).  lockf says
   
        All locks for a process are released upon
        the first close of the file, even if the process still has the file
        opened, and all locks held by a process are released when the process
        terminates.
   
   and
   
        When a file descriptor is closed, all locks on the file from the
        calling process are deleted, even if other file descriptors for that
        file (obtained through dup() or open(), for example) still exist.
   
   which seems to imply (but doesn't actually say) that HPUX keeps track of
   exactly which process took out the lock, even if the file is held open
   by multiple processes.
   
   This all doesn't look good for using file locks in the way I had in
   mind :-( ... but considering that all these man pages seem pretty vague,
   maybe some direct experimentation is called for.
   
   			regards, tom lane
   
   

3. Re: On file locking

   Curt Sampson <cjs@cynic.net> — 2003-02-02T19:27:28Z

   On Sun, 2 Feb 2003, Tom Lane wrote:
   
   > This all doesn't look good for using file locks in the way I had in
   > mind :-( ... but considering that all these man pages seem pretty vague,
   > maybe some direct experimentation is called for.
   
   Definitely. I wonder about the NetBSD manpage quotes in the post you
   followed up to, given that last time I checked flock() was implmented,
   in the kernel, using fcntl(). Either that's changed, or the manpages
   are unclear or lying.
   
   This has been my experience in the past; locking semantics are subtle
   and unclear enough that you really need to test for exactly what you
   want at build time on every system, and you've got to do this testing
   on the filesystem you intend to put the locks on. (So you don't, e.g.,
   test a local filesystem but end up with data on an NFS filesystem with
   different locking semantics.) That's what procmail does.
   
   Given this, I'm not even sure the whole idea is worth persuing. (Though
   I guess I should find out what NetBSD is really doing, and fix the
   manual pages correspond to reality.)
   
   cjs
   -- 
   Curt Sampson  <cjs@cynic.net>   +81 90 7737 2974   http://www.netbsd.org
       Don't you know, in this new Dark Age, we're all light.  --XTC