Re: Help on posix file lock semantics

[Gunnar Andre Dalsnes <hardon at online dot no>]

At 20.08.01 23:25 , you wrote:
>On Mon, Aug 20, 2001 at 10:55:54PM +0200, Gunnar Andre Dalsnes wrote:
> > At 20.08.01 13:18 , you wrote:
> > >On Sun, Aug 19, 2001 at 11:06:13PM +0200, Gunnar Andre Dalsnes wrote:
> > >
> > >      There will be at most one type of lock set for each byte in the
> > >      file. Before a successful return from an F_SETLK or an F_SETLKW
> > >      request when the calling process has previously existing locks on
> > >      bytes in the region specified by the request, the previous lock
> > >      type for each byte in the specified region will be replaced by the
> > 
> > And locks outside of upgraded regions are resized to fit and kept as standalone locks?
> > 
> > Example:
> > A file has write lock from off. 10 to 20 and read lock from off. 30 to 40.
> > A new read lock from off. 15 to 35 upgrades both existing overlapped regions.
> > 
> > Now we have three locks?
> > -write lock off. 10 to 15
> > -read lock off. 15 to 35
> > -read lock off. 35 to 40
> > 
> > Or maybe they merged? 
> > -write lock off. 10 to 15
> > -read lock off. 15 to 40
> > 
> > The reason i ask is that i want F_GETLK to behave correctly if called afterwards.
>
>You got me there. :)
>
>I don't see anything in the standard that covers it, so I guess
>it's implementation defined.
>
>Otoh, is it really that important?

I really dunno...

Attention mailing list: Anyone needs this?


> > >If someone already holds an exclusive/write lock, and you try to
> > >get a read/shared lock, and used F_SETLKW, you will have to wait
> > >until that lock is gone, and you can get it.
> > >
> > >Same goes for getting any lock when someone already has an
> > >exclusive/write lock.
> > >
> > >Read locks can't block each other, but write locks block
> > >everything else.
> > 
> > Stupid me:-) I get it!
> > But one thing's for sure:
> > A lock of any type can't block any lock attempt from same process (because of upgrading), right?
>
>Right, It only says the request will fail if the lock is hold by
>an other process.
>
>
>Kurt

Gunnar


--
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple
Bug reporting:         http://cygwin.com/bugs.html
Documentation:         http://cygwin.com/docs.html
FAQ:                   http://cygwin.com/faq/