No! Open on an exclusive file has the same races. No problems on Froggie .. no servers with clunk semantics. The first I encountered was Bosch's video streamer. Nemo obviously has concerns.
Catch a run. brucee On Fri, Oct 29, 2010 at 10:51 AM, Gorka Guardiola <pau...@gmail.com> wrote: > 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. > >
