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
Date: Mon, 20 Aug 2001 13:18:24 +0200
From: Kurt Roeckx <Q AT ping DOT be>
To: Gunnar Andre Dalsnes <hardon AT online DOT no>
Cc: cygwin AT cygwin DOT com
Subject: Re: Help on posix file lock semantics
Message-ID: <20010820131824.A200@ping.be>
References: <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
X-Mailer: Mutt 1.0pre2i
In-Reply-To: <4.2.2.20010819225911.00b94970@pop.online.no>

On Sun, Aug 19, 2001 at 11:06:13PM +0200, Gunnar Andre Dalsnes wrote:
> 
> Issue 1:
> Affects: Uniprocess, CloseHandle (file)
> 
> Both win32 and posix discharges locks made by process when ends.
> 
> Win32 associate locks with handles. 
> If one of many handles for a file close, only locks made by that handle is discharged.
> 
> Posix associate lock with files.
> If one of many handles for a file close, all locks for file is discharged.

     All locks associated with a file for a given process are removed
     when a file descriptor for that file is closed by that process or
     the process holding that file descriptor terminates. Locks are not
     inherited by a child process created using fork().

This looks rather odd to me, but seems to be what the standard
tells.

I think he more associates the lock with the process, not the
file, or file descriptor/handle.  I was always under the
impression that it associated it with the file descriptor, which
would make more sense.

> 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
     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.

> Issue 4:
> Affects: Multiprocess, fcntl->F_SETLKW
> 
> Win32 wait infinite on blocking locks.
> 
> HELP! Posix wait on blocking locks, but may be interupted by primitive signals?

F_SETLKW can be interupted by a singal, yes, in which case it will
return -1.

The only way to get around this seems that you have to call win32
with F_SETLK, and sleep while it failed.


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/