From mboxrd@z Thu Jan  1 00:00:00 1970
MIME-Version: 1.0
In-Reply-To: <d555a1ae7e1735204d7ee20381034260@terzarima.net>
References: <AANLkTinEZZu-8qKfh6u3qdcJbcE6M_=eQjqBxP_2PkCG@mail.gmail.com>
	<d555a1ae7e1735204d7ee20381034260@terzarima.net>
Date: Thu, 28 Oct 2010 16:30:53 +0200
Message-ID: <AANLkTikj+kT7f_UHMmXeBXd1NmfqBWP7oaeShywowv3D@mail.gmail.com>
From: Gorka Guardiola <paurea@gmail.com>
To: Fans of the OS Plan 9 from Bell Labs <9fans@9fans.net>
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable
Subject: Re: [9fans] A little more ado about async Tclunk
Topicbox-Message-UUID: 703970de-ead6-11e9-9d60-3106f5b1d025

On Thu, Oct 28, 2010 at 2:12 PM, Charles Forsyth <forsyth@terzarima.net> wr=
ote:
> you're essentially replacing
> =A0 =A0 =A0 =A0f :=3D open(name, ...)
> =A0 =A0 =A0 =A0...
> =A0 =A0 =A0 =A0close(f)
>
> which runs as a sequential process, and subject to the usual rules for se=
quential
> composition, by
>
> =A0 =A0 =A0 =A0f :=3D open(name, ...)
> =A0 =A0 =A0 =A0...
> =A0 =A0 =A0 =A0spawn clunk(f)
>
> which introduces a race with an invisible anonymous process with no means=
 of synchronisation.
>
>


Wouldn=B4t a better way be?:

f :=3D 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.