On 6/2/05, Sherm Pendley <[EMAIL PROTECTED]> wrote: > On Jun 2, 2005, at 7:33 PM, Joel Rees wrote: > > > Race conditions don't go away just because you have high speed > > connections. > > Quite true, but high speed connections *do* shrink the time window, > considerably reducing the risk. Unless you have an application that > absolutely, positively, must *never* fail, you can easily get to a > point where the risk is too low to justify the effort of lowering it > even further. > > sherm--
Exactly. Race conditions don't go away even if you take the the network out of the connection entirely. There's still a very small even with the mv option. But the faster the copy can happen, the less chance of a request being issued while it's unsable. If it takes an hour to write a file, there's a pretty good change many people are going to get 505's or 404's. If it takes 1/10th of a second to shuffle some pointers, theres a pretty good chance no one will ever know. And "unusable" is really what we're talking about here, not race conditions. I don't think there's much potential for a true race condition. First, hopefully the OS is sane, and second, there's one reading process and one writing process. That's not problematic from a scheduling standpoint, unless I was absent the day tail got defined as a race condition; it's not exactly fertile ground for an infinte loop. The problem is that the OP would like for the web server to have access to a complete (old) file until the complete new file is available. And there are two solutions to that I can see: 1) get a connection fast enough to narrow the window of opportunity to within the bounds of acceptability, or 2) bait and switch. -- jay -------------------- daggerquill [at] gmail [dot] com http://www.engatiki.org
