mb@ttidca.TTI.COM (Michael Bloom) (01/30/89)
When adding the BSD flock call to my System V kernel, I was surprised to see that a count of exclusive locks is kept in the inode's i_exlockc field. Why bother to do this? Isn't the IEXLOCK flag bit sufficient since there can only be one exclusive lock at any one time? Am I missing something?
jfc@athena.mit.edu (John F Carr) (02/01/89)
In article <3775@ttidca.TTI.COM> mb@ttidca.tti.com (Michael Bloom) writes: >Why bother to do this? Isn't the IEXLOCK flag bit sufficient since there >can only be one exclusive lock at any one time? 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). -- John Carr "When they turn the pages of history, jfc@Athena.mit.edu When these days have passed long ago, bloom-beacon! Will they read of us with sadness athena.mit.edu!jfc For the seeds that we let grow?" --Neil Peart
mb@ttidca.TTI.COM (Michael Bloom) (02/02/89)
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 ...