Corinna Vinschen writes: > In theory this scenario could be worked around in Cygwin by bookkeeping > the present locks, plus a piece of code which unlocks all existing locks > in the given range when a lock or unlock request is coming in. However, > the really dismal fact is, that an unlock before a lock would never be > atomic. If the F_SETLK request unlocks an existing lock and then > another process gets a lock in the requested range, the first process > ends up with a failed fcntl call and no lock at all.
Thanks for the explanation, I'm beginning to see what the backoff / retry code in SQLite on WIndows is supposed to be doing (hopefully). Regards, Achim. -- +<[Q+ Matrix-12 WAVE#46+305 Neuron microQkb Andromeda XTk Blofeld]>+ Factory and User Sound Singles for Waldorf Blofeld: http://Synth.Stromeko.net/Downloads.html#WaldorfSounds -- 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
