Fwd: Options for getting mandatory locking in cygwin1.dll (was: Promote sqlite 3.7.13-1 from test status?)

Fwd: Options for getting mandatory locking in cygwin1.dll (was: Promote sqlite 3.7.13-1 from test status?)

[Terris Linenbach]

Here is a scenario that involves Cygwin Perl only.

I have a need for multiple Cygwin instances on the same box mainly due
to DLL bases and CPAN modules. I've already read through the endless
threads about both topics so there's no need to mention them. I have
good reasons to do what I'm doing.

Advisory locks don't work across cygwin instances. This is reasonable
but unexpected. That's not such a big deal - use the pidfile pattern
instead, until you realize that kill doesn't work across cygwin
instances either, so you can't check whether the process that owns the
lock is alive. So we are dealing with the possibility of zombie locks,
as well as being extra careful to avoid killing processes. Which, of
course, is impossible in practice.

It would be fantastic if there was eventually a way to get advisory
locks to work across cygwin installations. Mandatory locks would work
too. Or perhaps I should try Perl's own flock implementation.

Any feedback would be gratefully appreciated.


Terris

>
> Greetings, Corinna Vinschen!
>
> > A "mand" mount option sounds like a really interesting idea, together
> > with the special group permission settings as described in the Linux
> > fcntl(2) man page.  Maybe we can even relax that by making the "mand"
> > option the default setting, so the correct file permissions would be
> > the only requirement by default.  Ok, this also requires to use a
> > filesystem with real file permissions, so FAT or "noacl" mounted
> > filesystems are out of th question, but I can live with that just fine.
>
> Sorry byt I can't live with it.
> Setting "noacl" mounts aside from "mand" will force me to choose one or
> another. And it wouldn't be a choice in Cygwin's favor.
> Forced use of POSIX'ised permissions have higher probability of breaking
> existing Windows applications, than using POSIX "suggestive" locks instead of
> appropriate strict locks could harm Cygwin applications.
>
> > The problem with this approach is a non-technical one:  In the next
> > couple of months I have probably no time to implement it.  It's not
> > overly tricky to implement it, as far as I can see, but, as usual,
> > somebody has to do it.  So if anybody would like to take a stab at
> > it...
>
>
> --
> WBR,
> Andrey Repin (anrdae...@freemail.ru) 17.08.2012, <17:01>

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

Re: Options for getting mandatory locking in cygwin1.dll (was: Promote sqlite 3.7.13-1 from test status?)

[Corinna Vinschen]

On Aug 31 10:59, Terris Linenbach wrote:
> Here is a scenario that involves Cygwin Perl only.
> 
> I have a need for multiple Cygwin instances on the same box mainly due
> to DLL bases and CPAN modules. I've already read through the endless
> threads about both topics so there's no need to mention them. I have
> good reasons to do what I'm doing.
> 
> Advisory locks don't work across cygwin instances. This is reasonable
> but unexpected.

This won't change.  Ever.  Advisory locks rely on the Cygwin DLL
holding handles to certain objects within the native NT namespace
depending on the Cygwin installation.  You cannot have both, using
two independent Cygwin DLL installations working concurrently, and
sharing of internal resources.


Corinna

-- 
Corinna Vinschen                  Please, send mails regarding Cygwin to
Cygwin Project Co-Leader          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

Re: Options for getting mandatory locking in cygwin1.dll (was: Promote sqlite 3.7.13-1 from test status?)

[Andrey Repin]

Greetings, Corinna Vinschen!

> A "mand" mount option sounds like a really interesting idea, together
> with the special group permission settings as described in the Linux
> fcntl(2) man page.  Maybe we can even relax that by making the "mand"
> option the default setting, so the correct file permissions would be
> the only requirement by default.  Ok, this also requires to use a
> filesystem with real file permissions, so FAT or "noacl" mounted
> filesystems are out of th question, but I can live with that just fine.

Sorry byt I can't live with it.
Setting "noacl" mounts aside from "mand" will force me to choose one or
another. And it wouldn't be a choice in Cygwin's favor.
Forced use of POSIX'ised permissions have higher probability of breaking
existing Windows applications, than using POSIX "suggestive" locks instead of
appropriate strict locks could harm Cygwin applications.

> The problem with this approach is a non-technical one:  In the next
> couple of months I have probably no time to implement it.  It's not
> overly tricky to implement it, as far as I can see, but, as usual,
> somebody has to do it.  So if anybody would like to take a stab at
> it...


--
WBR,
Andrey Repin (anrdaemon@freemail.ru) 17.08.2012, <17:01>

Sorry for my terrible english...


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

Re: Options for getting mandatory locking in cygwin1.dll (was: Promote sqlite 3.7.13-1 from test status?)

[Corinna Vinschen]

On Aug 16 13:51, Warren Young wrote:
> On 8/16/2012 6:26 AM, Corinna Vinschen wrote:
> >On Aug 16 06:01, Warren Young wrote:
> >>Advisory locking only works when all players cooperate.  We can't
> >>assume that on Windows, unless we set up an insular Cygwin ghetto.
> >
> >So, are you saying that Cygwin should use mandatory file locking?
> 
> Of course not.  That would be a disaster.
> 
> >You are aware that there's no chance at all to implement the UNIX
> >locking API calls correctly this way since Windows locking has nothing
> >in common with UNIX locking except for the word "locking".
> 
> Not even on a per-process basis (cygwin_set_mandatory_locking(1)),
> in conjunction with fcntl(F_SETLK)?  That's how SQLite's
> unixFileLock() function is implemented.
> 
> That is, this proposal would put the DLL in a mode where it called
> LockFileEx() to establish the reader/writer lock byte ranges instead
> of using its private advisory locking scheme.
> 
> Alternately, Cygwin could follow Linux and implement 'mount -o
> mand'. You could get mandatory locking on just your svn checkout
> tree this way, for example.  It would apply to all Cygwin programs,
> not just svn/SQLite, but it shouldn't be any more problematic than
> normal day to day Windows use.  Cygwin programs not run within that
> mount wouldn't be affected.

A "mand" mount option sounds like a really interesting idea, together
with the special group permission settings as described in the Linux
fcntl(2) man page.  Maybe we can even relax that by making the "mand"
option the default setting, so the correct file permissions would be
the only requirement by default.  Ok, this also requires to use a
filesystem with real file permissions, so FAT or "noacl" mounted
filesystems are out of th question, but I can live with that just fine.

The problem with this approach is a non-technical one:  In the next
couple of months I have probably no time to implement it.  It's not
overly tricky to implement it, as far as I can see, but, as usual,
somebody has to do it.  So if anybody would like to take a stab at
it...


Corinna

-- 
Corinna Vinschen                  Please, send mails regarding Cygwin to
Cygwin Project Co-Leader          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

Re: Options for getting mandatory locking in cygwin1.dll (was: Promote sqlite 3.7.13-1 from test status?)

[Warren Young]

On 8/16/2012 6:26 AM, Corinna Vinschen wrote:
> On Aug 16 06:01, Warren Young wrote:
>> Advisory locking only works when all players cooperate.  We can't
>> assume that on Windows, unless we set up an insular Cygwin ghetto.
>
> So, are you saying that Cygwin should use mandatory file locking?

Of course not.  That would be a disaster.

> You are aware that there's no chance at all to implement the UNIX
> locking API calls correctly this way since Windows locking has nothing
> in common with UNIX locking except for the word "locking".

Not even on a per-process basis (cygwin_set_mandatory_locking(1)), in 
conjunction with fcntl(F_SETLK)?  That's how SQLite's unixFileLock() 
function is implemented.

That is, this proposal would put the DLL in a mode where it called 
LockFileEx() to establish the reader/writer lock byte ranges instead of 
using its private advisory locking scheme.

Alternately, Cygwin could follow Linux and implement 'mount -o mand'. 
You could get mandatory locking on just your svn checkout tree this way, 
for example.  It would apply to all Cygwin programs, not just 
svn/SQLite, but it shouldn't be any more problematic than normal day to 
day Windows use.  Cygwin programs not run within that mount wouldn't be 
affected.

I'm aware that fcntl(F_SETLK) isn't thread-safe[1] but we're arguing "if 
it's good enough for Unix, it's good enough for Cygwin" here, aren't we? 
  The other objection in reference [1] is that it doesn't work with NFS, 
which doesn't matter to us here, I think.

If neither of those proposals will work, I think we'll have no choice 
but to continue to try and chase a SQLite specific solution.  You can't 
fix it on the Windows native side of things.  I doubt you can fix it in 
Subversion, and even if you could, that's no better than fixing it in 
SQLite.  Worse, actually, because then you've got a fix that affects 
only one program, not all SQLite dependents.


[1] http://0pointer.de/blog/projects/locking.html

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