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 <[email protected]> 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
