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