Mailing-List: contact cygwin-help AT sourceware DOT cygnus DOT com; run by ezmlm
List-Subscribe: <mailto:cygwin-subscribe AT sources DOT redhat DOT com>
List-Archive: <http://sources.redhat.com/ml/cygwin/>
List-Post: <mailto:cygwin AT sources DOT redhat DOT com>
List-Help: <mailto:cygwin-help AT sources DOT redhat DOT com>, <http://sources.redhat.com/ml/#faqs>
Sender: cygwin-owner AT sources DOT redhat DOT com
Delivered-To: mailing list cygwin AT sources DOT redhat DOT com
Message-Id: <4.2.2.20010820221811.00b9d9a0@mail.online.no>
X-Sender: hardon AT mail DOT online DOT no (Unverified)
X-Mailer: QUALCOMM Windows Eudora Pro Version 4.2.2 
Date: Mon, 20 Aug 2001 22:55:54 +0200
To: cygwin AT cygwin DOT com
From: Gunnar Andre Dalsnes <hardon AT online DOT no>
Subject: Re: Help on posix file lock semantics
Cc: Kurt Roeckx <Q AT ping DOT be>
In-Reply-To: <20010820131824.A200@ping.be>
References: <4 DOT 2 DOT 2 DOT 20010819225911 DOT 00b94970 AT pop DOT online DOT no>
 <4 DOT 2 DOT 2 DOT 20010819225911 DOT 00b94970 AT pop DOT online DOT no>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"

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/