This is the mail archive of the
cygwin
mailing list for the Cygwin project.
Re: Promote sqlite 3.7.13-1 from test status?
On Aug 16 04:30, Warren Young wrote:
> On 8/16/2012 2:50 AM, Corinna Vinschen wrote:
> >On Aug 16 07:41, Achim Gratz wrote:
> >>there's a race
> >>somewhere between calls from the Cygwin DLL and Windows file locking functions.
> >
> >Cygwin does not use Windows mandatory locking. The locking is entirely
> >implemented within the Cygwin DLL and is only advisory, as is befitting
> >for a POSIX envionment.
>
> Interesting. I never knew that. I'd assumed that since Cygwin
> occasionally gets tangled up with Windows mandatory locking (e.g.
> in-use DLL replacement) that it was playing by those rules all the
> time.
>
> >If you try to use the same file with a
> >non-Cygwin tool using Windows locking in parallel with a Cygwin tool,
> >you will get into trouble. The mandatory Windows locking will always
> >win and the Cygwin tool will fail.
>
> I think that nails the problem.
>
> SQLite has a lot of Windows and Cygwin specific code in it, and in
> large part, it treats Cygwin as "Windows", including use of the
> Win32 API LockFile(). (See osLockFile() and winLock*() in
> sqlite3.c.)
*shudder*
> When you force it to build in "Unix mode", all that code gets
> ifdef'd out, replaced by an entirely different set of OS-specific
> I/O wrappers, such as unixLock().
That sounds good to me.
> So, what you did with that requested change, Achim, is prevented
> Cygwin svn from winning any fights over ownership of .svn/wc.db.
So what? Don't use native Windows tools in parallel accessing the
same file. Full stop.
> This could have happened to anything built against Cygwin SQLite,
> where there is also another native Windows program trying to access
> the same DB file. The only Subversion-specific thing about this
> problem was how Subversion was coded to react when it happened.
> Another program might not say "disk I/O error," but would somehow
> fail nevertheless.
>
> Reverting this change put Cygwin SQLite based programs back on an
> even footing with native SQLite based programs.
>
> I gotta say, I'm not wild about the way SQLite treats Cygwin as
> Windows, bypassing the POSIX APIs so often. Yet, you can see the
> logic, at least in the case of file locking. Mandatory file locking
> is a very good thing in the case of SQLite.
Why should mandatory locking be better here, while it's quite naturally
using advisory locking in the entire UNIX world?
To put it another way: A native Windows SQLight can do whatever it
wants, I don't care. But a Cygwin SQLight should use POSIX functions
in the first place and, as such, use POSIX advisory file locking
functions and no Windows functions at all, if not absolutely necessary.
And this: If you think it's absolutely necessary to use some Windows
functions, what is it, and why?
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