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?
> >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
--
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/
