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 <bruce.ellis@gmail.com> 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