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

[Francisco J Ballesteros <nemo@lsub.org>]

One problem I have with delayed clunks is that when you have caches or the like,
close might fail. Not an issue on Inferno, but, I'd still like to be
able to get back in sync
at close time if only to be able to check that everything's ok and
safe in the server.


On Thu, Oct 28, 2010 at 4:30 PM, Gorka Guardiola <paurea@gmail.com> wrote:
> On Thu, Oct 28, 2010 at 2:12 PM, Charles Forsyth <forsyth@terzarima.net> wrote:
>> you're essentially replacing
>>        f := open(name, ...)
>>        ...
>>        close(f)
>>
>> which runs as a sequential process, and subject to the usual rules for sequential
>> composition, by
>>
>>        f := open(name, ...)
>>        ...
>>        spawn clunk(f)
>>
>> which introduces a race with an invisible anonymous process with no means of synchronisation.
>>
>>
>
>
> Wouldn´t a better way be?:
>
> f := open(name, ...)
> tclunk(f);
>
> spawn deallocfid(f); //and whatever needs to be done on Rclunk
>
> Hmm, it would be more like sending the Tclunk and not waiting for the
> response. That would mean
> that the fid cannot be unmarked for reuse until the response is
> received (asynchronously), so it can
> be moved to a "stale fid" table to be deallocated later. Most of the
> semantics are the same.
>
> I agree that the performance gain is probably not enough to bother
> anyway. You are still doing all the
> walks and so on.
>
> Unless clunk means something in slang :-P.
>
> G.
>
>