From mboxrd@z Thu Jan 1 00:00:00 1970 MIME-Version: 1.0 In-Reply-To: References: <6b21211797cc4b5ff93802313f2fd94c@terzarima.net> From: Venkatesh Srinivas Date: Fri, 29 Oct 2010 12:28:00 -0400 Message-ID: To: Fans of the OS Plan 9 from Bell Labs <9fans@9fans.net> Content-Type: multipart/alternative; boundary=0016e6daa63e6221830493c3f2bd Subject: Re: [9fans] A little more ado about async Tclunk Topicbox-Message-UUID: 721c8eb8-ead6-11e9-9d60-3106f5b1d025 --0016e6daa63e6221830493c3f2bd Content-Type: text/plain; charset=UTF-8 erik quanstrom wrote: > what's a reasonable definition of "standard"? I've been using 'decent' in much the same way 'standard' or 'disk' is being used; I'd actually prefer nemo's idea of a QTDECENT qidtype to marking the file server. The original QTDECENT proposal (actually originally inverted logic, in the form of QTCTL) said this about indecent files: "this file does not behave like a regular file, do not cache and handle with care". I think stating it in the form: "indecent files require in-order issue _and_ completion of a 9p request stream from the perspective of the application making the system calls/generating 9p messages to the file service." There is a loose convention now of qid.version == 0 meaning something like 'indecent'. > roger, charles describe races in both async TClunk issue and async RClunk wait: r1 := ---- A: sekrit B: TOpen(name, ...) spawn TClunk TOpen(name, ...) TClunk(fid..) RClunk(yep! / nope!) ... Perhaps I'm being really thick, but this is the same scenario as a current: ---- A: explicit process B: ->TOpen(name, ...) <- ROpen(yea) -> TOpen(name, ...) <- ROpen(zzz) -> TClunk(fid) <- RClunk(fid) ... zzz := Yes, of course, on a 'decent' fileserver; 'no' on an indecent one, or with OEXCL in A's open. All the asynchronous issue opens is this concurrency issue with yourself (A against itself)... but it already exists if you don't use OEXCL in the (A against B) form. On Fri, Oct 29, 2010 at 11:59 AM, Bruce Ellis wrote: > this discussion was more interesting in thev UNIX room. froggie hasn't > hung up yet thru a serious thrashing this evening - and all the FSs > are synthetic - it has no disk. > > as much as i like philosophizing that's not my way. > > brucee > When you get a chance, could you describe your approach in more detail? Bruce Ellis also wrote: >> Roger Peppe wrote: >> even sending Tclunk synchronously is still problematic in quite a few scenarios, >> for the reasons i outlined above. > gee i thought i was the first to say deadly-embrace on this thread. > it's not only problematic it's wrong. just reiterating what little > shaun said circa 1999. Sorry, I don't see the embrace... when the original close() caller doesn't wait on the TClunk/RClunk pair, what would it stall on? What would the close process stall on? Thanks! -- vs --0016e6daa63e6221830493c3f2bd Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
erik quanstrom wrote:
> what's a reaso= nable definition of "standard"?

I've been using 'd= ecent' in much the same way 'standard' or 'disk' is bei= ng used; I'd actually prefer nemo's idea of a QTDECENT qidtype to m= arking the file server. The original QTDECENT proposal (actually originally= inverted logic, in the form of QTCTL) said this about indecent files: &quo= t;this file does not behave like a regular file, do not cache and handle wi= th care".

I think stating it in the form: "indecent files require in-order i= ssue _and_ completion of a 9p request stream from the perspective of the ap= plication making the system calls/generating 9p messages to the file servic= e." There is a loose convention now of qid.version =3D=3D 0 meaning so= mething like 'indecent'.

> roger, charles describe races in both async TClunk issue and async= RClunk wait:

r1 :=3D
----
A:=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 sekrit B:
TOpen(name, ...)=
spawn TClunk
TOpen(name, ...)
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0 TClunk(fid..)
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 RClunk(yep! / = nope!)
...

Perhaps I'm being really thick, but this is the sa= me scenario as a current:
----
A:=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0 explicit process B:
->TOpen(name, ...)
<- ROpen(ye= a)
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 -> TOpen(name, ...)
=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0 <- ROpen(zzz)
-> TClunk(fid)
<- RClunk(fid)
...

zzz :=3D Yes, of cours= e, on a 'decent' fileserver; 'no' on an indecent one, or wi= th OEXCL in A's open. All the asynchronous issue opens is this concurre= ncy issue with yourself (A against itself)... but it already exists if you = don't use OEXCL in the (A against B) form.

On Fri, Oct 29, 2010 at 11:59 AM, Bruce Ellis <bruce.ellis@gmail.com> = wrote:
this discussion was more interesting in thev UNIX room. froggie hasn't<= br> hung up yet thru a serious thrashing this evening - and all the FSs
are synthetic - it has no disk.

as much as i like philosophizing that's not my way.

brucee

When you get a chance, could you describe y= our approach in more detail?

Bruce Ellis also wrote:
>> Rog= er Peppe wrote:
>> even sending Tclunk synchronously is still prob= lematic in quite a few scenarios,
>> for the reasons i outlined above.
> gee i thought i was the = first to say deadly-embrace on this thread.
> it's not only probl= ematic it's wrong. just reiterating what little
> shaun said circ= a 1999.

Sorry, I don't see the embrace... when the original close() caller = doesn't wait on the TClunk/RClunk pair, what would it stall on? What wo= uld the close process stall on?

Thanks!
-- vs
--0016e6daa63e6221830493c3f2bd--