DomainKey-Signature: a=rsa-sha1; c=nofws; d=sourceware.org; h=list-id
	:list-unsubscribe:list-subscribe:list-archive:list-post
	:list-help:sender:date:from:to:subject:message-id:reply-to
	:references:mime-version:content-type:in-reply-to; q=dns; s=
	default; b=o1NtAVmHi8MGA4jdFfmUbu80f2ssl6oxaNB5oeIS8JngQqRYlnzEi
	f0JNCFmW1PoW7wYeBtifYVbOCNoFkq6D1JoTtLAWJeXXMKuMx2htmGmY3ZTQZ0+1
	OPWjYR/3SXNG3BKqENO19dtOSC+fsQ5ZeJkEnkcaJRtY8wTmUuA6i4=
Mailing-List: contact cygwin-help@cygwin.com; run by ezmlm
Sender: cygwin-owner@cygwin.com
Mail-Followup-To: cygwin@cygwin.com
Date: Wed, 5 Jun 2013 20:15:16 +0200
From: Corinna Vinschen <corinna-cygwin@cygwin.com>
To: cygwin@cygwin.com
Subject: Re: Mandatory file locking semantics
Message-ID: <20130605181516.GE3250@calimero.vinschen.de>
Reply-To: cygwin@cygwin.com
Mail-Followup-To: cygwin@cygwin.com
References: <51A7F547.6020509@etr-usa.com> <20130531092228.GB30659@calimero.vinschen.de> <51A900EF.2020606@etr-usa.com> <20130601105741.GC30659@calimero.vinschen.de> <20130602103125.GE13934@calimero.vinschen.de> <51ACD415.2090709@etr-usa.com> <20130604084815.GD19572@calimero.vinschen.de> <51AF6433.5050104@etr-usa.com> <20130605170246.GD3250@calimero.vinschen.de> <51AF7303.8060303@etr-usa.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Disposition: inline
In-Reply-To: <51AF7303.8060303@etr-usa.com>
User-Agent: Mutt/1.5.21 (2010-09-15)

On Jun  5 11:18, Warren Young wrote:
> On 6/5/2013 11:02, Corinna Vinschen wrote:
> >The burden to use it correctly is
> >on the application developer.
> 
> That's always true, for all APIs.
> 
> If a design change can make it more likely that application
> developers will use it correctly, shouldn't the design be changed?

The fcntl commands are int, and they never have to be or'ed together.
It's no problem to add yet another fcntl command.  They won't collide
with POSIX or Linux commands, there are a lot of commands to express
in an int.

Open flags are or'ed together and mode_t is also an int.  This means,
there's only room for 32 (actually 33) open flags, and POSIX and Linux
are adding open flags as they go along.  Linux already uses 19 of the 32
bits.  I'm not overly enthusiastic to add a non-POSIX, non-Linux flag
for the sake of something which will be used only in very rare
circumstances, if at all.

> It's not like anyone is actually depending on this yet.  Granted,
> it's now present in a release version of Cygwin, but you declared it
> preliminary.  I don't see that anyone can complain if the design
> changes before it's declared stable.

Actually, adding this stuff to Cygwin took almost four days of my
life as it is today.  And while doing something entirely different, I
was thinking about ways to hammer a more POSIXy (or BSDy) behaviour into
these dreaded Windows locks.  Needless to say that I always came up
empty handed, given the dethpicable(*) shortcomings of Windows locks.

An application using POSIX or BSD lock calls, expecting POSIX or BSD
behaviour, will be in for a surprise, and there's just no way around
that, unless the application *knows* how Windows locks work, and choses
an accommodating code path.

So far it's not even clear if you really can use it in sqlite.  Using
fcntl locks apparently does not work, does the flock code path?

Given all that, I'd appreciate if you'd first test if the whole effort
was even worth it.  If it works, we can talk about other options.  And
if it turns out that the whole exercise was useless, I'm more inclined
to rip out the entire mandatory locking code again.

Does that make sense, at least a bit?


Corinna


(*) Think Daffy Duck.


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