This is the mail archive of the
mailing list for the Cygwin project.
Re: Mandatory file locking semantics
- From: Corinna Vinschen <corinna-cygwin at cygwin dot com>
- To: cygwin at cygwin dot com
- Date: Wed, 5 Jun 2013 20:15:16 +0200
- Subject: Re: Mandatory file locking semantics
- References: <51A7F547 dot 6020509 at etr-usa dot com> <20130531092228 dot GB30659 at calimero dot vinschen dot de> <51A900EF dot 2020606 at etr-usa dot com> <20130601105741 dot GC30659 at calimero dot vinschen dot de> <20130602103125 dot GE13934 at calimero dot vinschen dot de> <51ACD415 dot 2090709 at etr-usa dot com> <20130604084815 dot GD19572 at calimero dot vinschen dot de> <51AF6433 dot 5050104 at etr-usa dot com> <20130605170246 dot GD3250 at calimero dot vinschen dot de> <51AF7303 dot 8060303 at etr-usa dot com>
- Reply-to: cygwin at cygwin dot com
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?
(*) Think Daffy Duck.
Corinna Vinschen Please, send mails regarding Cygwin to
Cygwin Maintainer cygwin AT cygwin DOT com
Problem reports: http://cygwin.com/problems.html
Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple