From mboxrd@z Thu Jan  1 00:00:00 1970
MIME-Version: 1.0
In-Reply-To: <AANLkTikj+kT7f_UHMmXeBXd1NmfqBWP7oaeShywowv3D@mail.gmail.com>
References: <AANLkTinEZZu-8qKfh6u3qdcJbcE6M_=eQjqBxP_2PkCG@mail.gmail.com>
	<d555a1ae7e1735204d7ee20381034260@terzarima.net>
	<AANLkTikj+kT7f_UHMmXeBXd1NmfqBWP7oaeShywowv3D@mail.gmail.com>
Date: Thu, 28 Oct 2010 16:39:47 +0200
Message-ID: <AANLkTimGUm68dTC+MNwoX60ZcXiCaAq0jQ3U4koLGOw3@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: 70414188-ead6-11e9-9d60-3106f5b1d025

>
> 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.

Assuming messages are not reordered.


--=20
- curiosity sKilled the cat