On Thu, Oct 28, 2010 at 10:18 PM, Charles Forsyth <fors...@terzarima.net> wrote: > > the race is that there's nothing to say that the clunk completes before the > process continues on to do something more, including some action that depends > on the clunk completing, > such as simply repeating the open. that open can fail if the mode or the name > imposes particular constraints; constraints that depend on the order of > events as > expressed by the process.
What you are saying is that the problem could be something like: -> Tclunk (do not wait for response) -> Topen (the file is exclusive) Then somehow in the server, Tclunk and Topen are reordered because they are managed by different threads and Topen gets an error because the file is already opened. This is a problem, I agree. > On Oct 28, 2010, at 10:32 PM, Venkatesh Srinivas <m...@acm.jhu.edu> wrote: > On a decent server, since clunk cannot fail and won't launch the missiles, > you can't really do anything that would depend on the result anyway. Tclunk may be a good time to commit to disk or do other unmissile like thing. You can switch to another cache after waiting for the Rclunk, for example. Decent or not indecent I am more and more conviced after this thread that Tclunk should be synchronous. Even in decent files Tclunk can have some side effects.
