From mboxrd@z Thu Jan 1 00:00:00 1970 MIME-Version: 1.0 In-Reply-To: References: Date: Thu, 28 Oct 2010 16:41:58 +0200 Message-ID: From: Francisco J Ballesteros To: Fans of the OS Plan 9 from Bell Labs <9fans@9fans.net> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Subject: Re: [9fans] A little more ado about async Tclunk Topicbox-Message-UUID: 70469804-ead6-11e9-9d60-3106f5b1d025 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 wrote: > On Thu, Oct 28, 2010 at 2:12 PM, Charles Forsyth = wrote: >> you're essentially replacing >> =C2=A0 =C2=A0 =C2=A0 =C2=A0f :=3D open(name, ...) >> =C2=A0 =C2=A0 =C2=A0 =C2=A0... >> =C2=A0 =C2=A0 =C2=A0 =C2=A0close(f) >> >> which runs as a sequential process, and subject to the usual rules for s= equential >> composition, by >> >> =C2=A0 =C2=A0 =C2=A0 =C2=A0f :=3D open(name, ...) >> =C2=A0 =C2=A0 =C2=A0 =C2=A0... >> =C2=A0 =C2=A0 =C2=A0 =C2=A0spawn clunk(f) >> >> which introduces a race with an invisible anonymous process with no mean= s of synchronisation. >> >> > > > Wouldn=C2=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. > >