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

[Eric Van Hensbergen <ericvh@gmail.com>]

On Fri, Oct 29, 2010 at 4:01 AM, Charles Forsyth <forsyth@terzarima.net> wrote:
>>What you are saying is that the problem could be something like:
>
>>-> Tclunk
>>(do not wait for response)
>>-> Topen (the file is exclusive)
>
> no, because what actually happens is closer to
>        A: Topen
>        ...
>        queue request to *another process* to send Tclunk
>        ...
>        A: Topen
>
> leading to either case 1
>        A: Topen
>        B: Tclunk
>        A: Topen
>
> or case 2
>        A: Topen
>        A: Topen
>        B: Tclunk
>
> depending on the scheduling of the two processes A and B
>
> introducing that other process introduces a new race, that simply did not exist before, because
> that other process didn't exist before. you always got case 1.
>
> and indeed, with the test i ran on the modified system usually it gets case 1
> because of timing, but eventually a case 2 shows up and the second open fails.
>

Just to make sure I understand things correctly, where does this mess
things up with standard (as opposed to synthetic) file systems?
ORCLOSE? OEXCL? Or is the primary concern the data flushing effect
implicit in clunk?  I'm inclined to agree with what I think gorka's
stance is, send the clunk, but have an option to asynchronously gather
the response (or make that the default and the option would be to
synchronously wait for the response (waitfd(2)?)  That would allow
apps that really care about the data sync semantics (or oexcl, etc.)
to make sure things have proceeded as planned, but wouldn't hold up
the 99% of other apps that don't give a care.

I guess my concern is that the always synchronous clunk for race-less
semantics is simple, but if we really are giving up a big chunk of
performance for the majority of uses and users, then it begs
re-evaluation of the approach.

       -eric