Curt Sampson <[EMAIL PROTECTED]> 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.


>From the NetBSD manual page:

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


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)

Ditto the Single Unix Standard versions 2 and 3.


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



---------------------------(end of broadcast)---------------------------
TIP 3: if posting/reading through Usenet, please send an appropriate
subscribe-nomail command to [EMAIL PROTECTED] so that your
message can get through to the mailing list cleanly

Reply via email to