Re: [9fans] A little more ado about async Tclunk

[Bruce Ellis <bruce.ellis@gmail.com>]

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 <paurea@gmail.com> wrote:
> On Thu, Oct 28, 2010 at 10:18 PM, Charles Forsyth <forsyth@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 <me@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.
>
>