Path: utzoo!utgpu!jarvis.csri.toronto.edu!mailrus!tut.cis.ohio-state.edu!bloom-beacon!apple!vsi1!wyse!mips!prls!philabs!ttidca!mb
From: mb@ttidca.TTI.COM (Michael Bloom)
Newsgroups: comp.unix.wizards
Subject: Re: Why is there an exclusive lock *count* ???
Message-ID: <3802@ttidca.TTI.COM>
Date: 2 Feb 89 02:24:01 GMT
References: <3775@ttidca.TTI.COM> <9036@bloom-beacon.MIT.EDU>
Reply-To: mb@ttidca.tti.com (Michael Bloom)
Organization: Citicorp/TTI, Santa Monica
Lines: 22

In article <9036@bloom-beacon.MIT.EDU> jfc@athena.mit.edu (John F Carr) writes:

>If a process forks while holding an exclusive lock, the number of locks
>increases by one (the lock remains until both parent and child have
>released it).

I'm wondering if perhaps that was the original intent, but that for
some reason it was not done that way.  From the man page:

     Locks are on files, not file descriptors.	That is, file
     descriptors duplicated 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.

Several people have written with the same answer referring to forks,
which would make sense except that I see no code supporting
incrementing i_exlockc for such cases. As this is also implied by the
man page, I'm still confused as to why exlockc is needed, unless it's
just present for future expansion - and even so, such a change could
introduce mucho incompatibility ...