This is the mail archive of the mailing list for the Cygwin project.

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]

Re: Help on posix file lock semantics

At 22.08.01 02:19 , you wrote:
>On Wed, Aug 22, 2001 at 01:31:39AM +0200, Gunnar Andre Dalsnes wrote:
> > At 22.08.01 00:37 , you wrote:
> > >
> > >Those 2 regions follow each other.  I think you're not supposed
> > >to merge those regions even if you could.
> > >
> > >If you don't merge regions in any other case, why would you
> > >suddenly want to merge them in the case of overlapping regions?
> > 
> > But if the (linux) os kernel does it automagically for us, I want to do it too:-)
>The comment for posix_lock_file() in fs/locks.s says: 
>"We merge adjacent locks whenever possible.", so I guess it
>always does.

To sort this out ofa, I went out and got a copy of Suse, and this was what I got:

-if any separate adjacent locks with same type were set, they merged. (regardless of type)
-if a new lock overlapped existing lock with same type, they merged. (regardless of type)
-if a new read lock overlapped existing write lock, the overlapped region changed to type read.
-if a new write lock overlapped existing read lock, the overlapped region changed to type write.

Not very unlike our assumptions:-)


Now I have enough info on this, to continue on the hard part, the coding...
Thank you very much for your time, Kurt:-)


Unsubscribe info:
Bug reporting:

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]