Mail Archives: cygwin/2001/08/20/17:02:14
At 20.08.01 13:18 , you wrote:
>On Sun, Aug 19, 2001 at 11:06:13PM +0200, Gunnar Andre Dalsnes wrote:
> > Issue 2:
> > Affects: Uniprocess, fcntl->F_SETLK->F_RDLCK/F_WRLCK/F_UNLCK
> >
> > Both win32 and posix allow only one type of lock per byte of a file.
> >
> > Win32 fails if any region overlap.
> >
> > Posix upgrades a lock if a region overlap.
> > HELP! A lock can upgrade multiple overlapped regions of any type?
> > HELP! An unlock can unlock multiple overlapped regions of any type?
>
> 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.
> new lock type. As specified above under the descriptions of shared
> locks and exclusive locks, an F_SETLK or an F_SETLKW request will
> (respectively) fail or block when another process has existing
> locks on bytes in the specified region and the type of any of those
> locks conflicts with the type specified in the request.
>
>So basicly, yes.
>
>It seems here it's about the process too, and not the
>filedescriptor itself.
>
> > Issue 3:
> > Affects: Multiprocess, fcntl->F_GETLK
> >
> > Win32 has no way of obtaining blocking locks.
> >
> > Posix can obtaing blocking read locks or both.
> > HELP! How can readlocks be blocking if locks are upgradeable (uniprocess)?
> > There is no such thing as blocking read locks among multiple processes eighter!
> > All i can think of is blocking write locks among multiple processes.
>
>I'm a little confused by what you're all saying.
>
>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?
>Kurt
Thanks for your help!
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/
- Raw text -