delorie.com/archives/browse.cgi | search |
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
webmaster | delorie software privacy |
Copyright © 2019 by DJ Delorie | Updated Jul 2019 |