Mail Archives: cygwin/2001/08/20/07:20:29
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/
- Raw text -