X-Recipient: archive-cygwin AT delorie DOT com X-SWARE-Spam-Status: No, hits=-3.8 required=5.0 tests=AWL,BAYES_00,KHOP_THREADED,RCVD_IN_DNSWL_NONE,RP_MATCHES_RCVD,SPF_HELO_PASS X-Spam-Check-By: sourceware.org To: cygwin AT cygwin DOT com From: Achim Gratz <Stromeko AT nexgo DOT de> Subject: Re: Promote sqlite 3.7.13-1 from test status? Date: Tue, 05 Feb 2013 20:51:14 +0100 Lines: 33 Message-ID: <87k3qmedzh.fsf@Rainer.invalid> References: <announce DOT 5029275C DOT 4040009 AT etr-usa DOT com> <502C0B7D DOT 10909 AT etr-usa DOT com> <loom DOT 20120816T092134-266 AT post DOT gmane DOT org> <20120816085016 DOT GB5536 AT calimero DOT vinschen DOT de> <502CCBB1 DOT 2070600 AT etr-usa DOT com> <20120816105507 DOT GD17546 AT calimero DOT vinschen DOT de> <502CE120 DOT 4050900 AT etr-usa DOT com> <20120816122654 DOT GG17546 AT calimero DOT vinschen DOT de> <502D1967 DOT 7090705 AT etr-usa DOT com> <20120816160656 DOT M21257 AT ds DOT net> <502D3A5C DOT 7010500 AT etr-usa DOT com> <00ad01cd7bf6$7cc68a50$76539ef0$@motionview3d.com> <1345169297 DOT 10004 DOT 10 DOT camel AT YAAKOV04> Mime-Version: 1.0 Content-Type: text/plain User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/24.2.92 (gnu/linux) X-IsSubscribed: yes Mailing-List: contact cygwin-help AT cygwin DOT com; run by ezmlm List-Id: <cygwin.cygwin.com> List-Subscribe: <mailto:cygwin-subscribe AT cygwin DOT com> List-Archive: <http://sourceware.org/ml/cygwin/> List-Post: <mailto:cygwin AT cygwin DOT com> List-Help: <mailto:cygwin-help AT cygwin DOT com>, <http://sourceware.org/ml/#faqs> Sender: cygwin-owner AT cygwin DOT com Mail-Followup-To: cygwin AT cygwin DOT com Delivered-To: mailing list cygwin AT cygwin DOT com Yaakov (Cygwin/X) writes: > So you're saying that it is more important for Cygwin's sqlite3 to work > with a Windows program than it is for it to work properly with other > Cygwin libraries and programs? That doesn't sound very pragmatic to me. > Software built for Cygwin should _always_ follow *NIX behaviour. I've had a few minutes to contemplate the SQLite source code. Aside from the different API used, it appears that the _real_ difference that's responsible for getting these "disk I/O" errors with the POSIX code is that for Windows (and Windows only) SQLite implements a retry-on-failure, complete with exponentially increasing backoff times. There's two ways to test that theory: one is to set the #DEFINE for the Windows code so that the retry code is not compiled in (or rendered ineffective): this should result in just about the same failures that were seen with the POSIX version. Secondly, to re-implement that retry-on-failure code in the POSIX section, which should get rid of these problems altogether. I'm a bit swamped with real work to do, so I wouldn't mind if someone could try the first option to confirm that it really delivers the same sort of interference with TortoiseSVN. If this is indeed the case, it would instill a greater confidence that the second option would actually solve the problem in the proper way. Regards, Achim. -- +<[Q+ Matrix-12 WAVE#46+305 Neuron microQkb Andromeda XTk Blofeld]>+ SD adaptation for Waldorf rackAttack V1.04R1: http://Synth.Stromeko.net/Downloads.html#WaldorfSDada -- 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