Re: sqlite3: bug with monotone

[Corinna Vinschen <corinna-cygwin at cygwin dot com>]

On Jun  1 13:35, Corinna Vinschen wrote:
> On Jun  1 12:57, Corinna Vinschen wrote:
> > There's a lot to recommend not using mandatory locking at all, unless in
> > very limited circumstances where interoperability with native
> > applications using mandatory locking is required.  For one thing, this
> > doesn't occur very often, since mandatory record locking isn't used
> > a lot, not even on Windows.  But what's more important is that Windows
> > mandatory record locking works not as the user can usually expect from
> > fcntl or flock: Windows locks are per-process/per-handle.  Locks are not
>                                     ^^^^^^^^^^^^^^^^^^^^^^
> 
> Make that "per-process/per-file object".
> 
> To clarify: The file object is the OS datastructure the handles refer
> to.  A duplicated handle refers to the same file object, while a handle
> to the same file created with CreateFile refers to another file object.
> 
> Duplicated handles within the same process share the locks.  Different
> handles to the same file created with CreateFile don't share the locks.
> 
> Duplicated handles to the same file object in another process (via
> inheritance or an explicit DuplicateHandle) don't share the locks.

Oh and, while I'm at it, here's another inconsistency:

fcntl locks, when owned, can be overwritten with another lock type
(F_RDLCK/F_WRLCK) without having to unlock the existing lock first.
fcntl locks can be locked and unlocked byte per byte on an as needed
basis.  Locks are split and merged as you lock along.

This doesn't work at all with Windows mandatory locks.  The owning
handle can overwrite read locks with other read locks, but they are not
merged.  Rather they add up and each of them has to be explicitly
unlocked to get out of the way.  The owning handle can't overwrite a
read lock with a write lock at all.  The owning handle can't overwrite a
write lock with an identical write lock.  Locked regions can't be
unlocked partially, they have to be unlocked exactly the same offset and
length as they have been locked.  Therefore, there's no atomic way to
convert arbitrary regions from one lock type to another, unless it's
guaranteed that the lock/unlock calls are guarded in a cooperative way.


Corinna

-- 
Corinna Vinschen                  Please, send mails regarding Cygwin to
Cygwin Maintainer                 cygwin AT cygwin DOT com
Red Hat

--
Problem reports:       http://cygwin.com/problems.html
FAQ:                   http://cygwin.com/faq/
Documentation:         http://cygwin.com/docs.html
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple