Re: [9fans] A little more ado about async Tclunk

Re: [9fans] A little more ado about async Tclunk

[erik quanstrom]

> months ago, i did test an example on the system that "just works", by the way,
> and it did fail. it often takes a few attempts for it to fail,
> because it depends on scheduling (often the system completes the clunk before
> returning to the original process), but there's nothing to stop it failing immediately.

:-)  had a bit of hardware with a race that mostly worked.  mean time to failure
for a single unit was ~40 days.  unfortunately, there wasn't just one, there were 1000.

- erik

[9fans] A little more ado about async Tclunk

[Venkatesh Srinivas]

[-- Attachment #1: Type: text/plain, Size: 1351 bytes --]

Hi folks,

I just committed a very simple implementation of asynchronous TClunk to
inferno-npe. The implementation will only defer sending clunks when MCACHE
is specified on the mount (via the new -j option to Inferno's mount,
analogous to Plan 9's mount -C) and when the file is not marked ORCLOSE. The
implementation is very simple -- I queue the RPCs devmnt would issue
synchronously and send them from a single kproc, one-after-another. There is
no attempt to overlap the TClunks. There is no logic to handle flushing a
deferred clunks on an unmount yet. The diff is not as clean as I would like,
but it works.

I connected from an inferno-npe client to an inferno-os server, sharing the
Plan9 source tree from August 16th and measured the time required for fcp -R
16 -W 16 to get the sources to /plan9/sys/src/cmd/cwfs and to get
/plan9/sys/src/9.  The server is approximately 15ms away from the client;
both are running Linux.

For the cwfs sources, it takes me an average of 5.68sec (stdev 0.57s, 6
tests) issuing synchronous clunks (the default) and an average of 4.54sec
(stdev 0.31s, 6 tests) issuing asynchronous clunks.

For the 9 kernel sources, it took about 51s with synchronous clunks, about
41s with asynchronous clunks on. I only did 3 tries with the 9 sources.

Thought this might be interesting...
-- vs

[-- Attachment #2: Type: text/html, Size: 1501 bytes --]

Re: [9fans] A little more ado about async Tclunk

[erik quanstrom]

> I just committed a very simple implementation of asynchronous TClunk to
> inferno-npe. The implementation will only defer sending clunks when MCACHE
> is specified on the mount (via the new -j option to Inferno's mount,
> analogous to Plan 9's mount -C) and when the file is not marked ORCLOSE. The
> implementation is very simple -- I queue the RPCs devmnt would issue
> synchronously and send them from a single kproc, one-after-another. There is
> no attempt to overlap the TClunks. There is no logic to handle flushing a
> deferred clunks on an unmount yet. The diff is not as clean as I would like,
> but it works.

how do you flow control the clunking processes?  are you using
qio?  if so, what's the size of the buffer?

also, do you have any test results for different latentices?  how
about a local network with ~0.5ms rtt and a long distance connection
at ~150ms?

have you tried this in user space?  one could imagine passing the
fds to a seperate proc that does the closes without involving the kernel.

- erik

Re: [9fans] A little more ado about async Tclunk

[Bruce Ellis]

I explained to VS that Research Inferno has been doing it for 10 years.

A much simpler approach. Solves your problems. Sorry that
wing-commander can't package it for today.

brucee

On Wed, Oct 27, 2010 at 3:23 PM, erik quanstrom <quanstro@quanstro.net> wrote:
>> I just committed a very simple implementation of asynchronous TClunk to
>> inferno-npe. The implementation will only defer sending clunks when MCACHE
>> is specified on the mount (via the new -j option to Inferno's mount,
>> analogous to Plan 9's mount -C) and when the file is not marked ORCLOSE. The
>> implementation is very simple -- I queue the RPCs devmnt would issue
>> synchronously and send them from a single kproc, one-after-another. There is
>> no attempt to overlap the TClunks. There is no logic to handle flushing a
>> deferred clunks on an unmount yet. The diff is not as clean as I would like,
>> but it works.
>
> how do you flow control the clunking processes?  are you using
> qio?  if so, what's the size of the buffer?
>
> also, do you have any test results for different latentices?  how
> about a local network with ~0.5ms rtt and a long distance connection
> at ~150ms?
>
> have you tried this in user space?  one could imagine passing the
> fds to a seperate proc that does the closes without involving the kernel.
>
> - erik
>
>

Re: [9fans] A little more ado about async Tclunk

[Charles Forsyth]

>Sorry that wing-commander can't package it for today.

sorry old boy, it wasn't LMF: at first we thought it was a wizard wheeze, but one of the sprogs had a prang with the bally old semantics and the other brass hats ordered it back to the boffins

Re: [9fans] A little more ado about async Tclunk

[Gorka Guardiola]

On Wed, Oct 27, 2010 at 3:50 PM, Charles Forsyth <forsyth@terzarima.net> wrote:
>>Sorry that wing-commander can't package it for today.
>
> sorry old boy, it wasn't LMF: at first we thought it was a wizard wheeze, but one of the sprogs had a prang with the bally old semantics and the other brass hats ordered it back to the boffins
>
>

That took all my google-fu to read. Please either take it easy on the
slang or provide
us johnny foreigners with some sort of translation.

--
- curiosity sKilled the cat

Re: [9fans] A little more ado about async Tclunk

[Francisco J Ballesteros]

I'm reaching out for Vaughan right now.
You might google for that if that's an unknown...

On Wed, Oct 27, 2010 at 3:53 PM, Gorka Guardiola <paurea@gmail.com> wrote:
> On Wed, Oct 27, 2010 at 3:50 PM, Charles Forsyth <forsyth@terzarima.net> wrote:
>>>Sorry that wing-commander can't package it for today.
>>
>> sorry old boy, it wasn't LMF: at first we thought it was a wizard wheeze, but one of the sprogs had a prang with the bally old semantics and the other brass hats ordered it back to the boffins
>>
>>
>
> That took all my google-fu to read. Please either take it easy on the
> slang or provide
> us johnny foreigners with some sort of translation.
>
> --
> - curiosity sKilled the cat
>
>

Re: [9fans] A little more ado about async Tclunk

[John Floren]

On Wed, Oct 27, 2010 at 9:53 AM, Gorka Guardiola <paurea@gmail.com> wrote:
> On Wed, Oct 27, 2010 at 3:50 PM, Charles Forsyth <forsyth@terzarima.net> wrote:
>>>Sorry that wing-commander can't package it for today.
>>
>> sorry old boy, it wasn't LMF: at first we thought it was a wizard wheeze, but one of the sprogs had a prang with the bally old semantics and the other brass hats ordered it back to the boffins
>>
>>
>
> That took all my google-fu to read. Please either take it easy on the
> slang or provide
> us johnny foreigners with some sort of translation.
>

It's perfectly ordinary banter, Squiffy. Bally Jerry ... pranged his
kite right in the how's yer father ... hairy blighter, dicky-birdied,
feathered back on his Sammy, took a waspy, flipped over on his Betty
Harper's and caught his can in the Bertie.

Re: [9fans] A little more ado about async Tclunk

[Eric Van Hensbergen]

On Wed, Oct 27, 2010 at 8:50 AM, Charles Forsyth <forsyth@terzarima.net> wrote:
>>Sorry that wing-commander can't package it for today.
>
> sorry old boy, it wasn't LMF: at first we thought it was a wizard wheeze, but one of the sprogs had a prang with the bally old semantics and the other brass hats ordered it back to the boffins
>

What sort of trouble?  Did one o' t' cross beams's gone out o' skew on
t' treadle?

More specifically, with the semantic restrictions that VS imposes, are
their remaining semantic problems when using this with cache-able file
systems?

       -eric

Re: [9fans] A little more ado about async Tclunk

[Venkatesh Srinivas]

[-- Attachment #1: Type: text/plain, Size: 3369 bytes --]

First, let me hop up and down and say -- this was me seeing what could be
accomplished in roughly two hours of hacking; this is by-far not the best
(or even a near approximation of) way to accomplish delayed TClunk. There
was no thought given at all to how to handle build-up of files to close or
how to overlap sending TClunks. I do track the peak number of outstanding
files to close; in this simple implementation, which fcp -R 16 -W 16-ing
down the p9 kernel sources, the peak waiting files to close I've seen was
10. I did not try out using more than one clunk process.

brucee solved this ten years ago; I'd love to hear how. Plan 9 has had
delayed close for tearing down fdgrps for nearly 4 years; dual-purposing
that logic to handle this case would be very straightforward.

erik quanstrom wrote:
>
> how do you flow control the clunking processes?  are you using
> qio?  if so, what's the size of the buffer?
>
> also, do you have any test results for different latentices?  how
> about a local network with ~0.5ms rtt and a long distance connection
> at ~150ms?
>
> have you tried this in user space?  one could imagine passing the
> fds to a seperate proc that does the closes without involving the kernel.
>

The clunking process just grabs Chans to close off a list, clunks one at a
time, and then sleeps if the list is empty. Its woken by a defered clunk
call. I tried out a little hysteresis there, to allow it to sleep for longer
but to burst close requests above another threshold, but that was
considerably slower overall than even the default (sync Clunk case). I do
not use qio. There is no limit on the number of outstanding files.

If you'd like to look it over, the main diff is visible at:
http://code.google.com/p/inferno-npe/source/detail?r=09a2e719616e1c842e602485edee9d03020909a6;
plan9 folks will notice a strong similarity to 9/port/chan.c:ccloseq
and
:closeproc.

I do not have tests at different latencies (reliable ones anyway); for
whatever reason, sources.cs.bell-labs.com was varying between 20ms and 300ms
from me yesterday, even in short timespans. The code is very easy to test
though - just grab and build inferno-npe and pass the '-j' flag to mount in
addition to whatever you'd normally use. You can monitor the number of files
waiting to close by reading /dev/vmstat.

I've not tried this in userspace (recently). Wes and I did try it about a
year ago as a side to the Journal Callbacks work; I'd have to look back to
see what the numbers looked like then, but iirc there was a significant
penalty to using our user-wrapper process and rewriting lots of 9p traffic,
though that was one of my first Limbo programs and could massively be
improved upon.

Eric Van Hensbergen wrote:
> More specifically, with the semantic restrictions that VS imposes, are
> their remaining semantic problems when using this with cache-able file
> systems?

All this approach does is delay TClunk messages, generally very little, and
only on files not marked ORCLOSE (perhaps it should also consider OEXCL) and
only on mounts flagged Sys->MCACHE. It would certainly be possible to write
a file server for which this approach is bad, but for the vast majority of
ones, this is a safe optimization. It does not depend on MCACHE caching;
inferno's port/cache.c is just a stub.

-- vs

[-- Attachment #2: Type: text/html, Size: 3846 bytes --]

Re: [9fans] A little more ado about async Tclunk

[erik quanstrom]

On Wed Oct 27 10:49:59 EDT 2010, me@endeavour.zapto.org wrote:

> First, let me hop up and down and say -- this was me seeing what could be
> accomplished in roughly two hours of hacking; this is by-far not the best
> (or even a near approximation of) way to accomplish delayed TClunk.

i don't think you need to defend yourself.  if it weren't interesting,
no questions would be asked.

i'm still curious to know what you would see by modifiying your target
program to drop the fds in a seperate thread.

- erik

Re: [9fans] A little more ado about async Tclunk

[Venkatesh Srinivas]

[-- Attachment #1: Type: text/plain, Size: 178 bytes --]

Oh, no, it wasn't meant as a defense! It was much more a 'hmm, only two
hours can produce fairly solid performance gains; perhaps this deserves a
more serious look'.

-- vs

[-- Attachment #2: Type: text/html, Size: 215 bytes --]

Re: [9fans] A little more ado about async Tclunk

[Bruce Ellis]

It does. And eliminates deadly embraces when servers misbehave.

No wuckers.

brucee

On Thu, Oct 28, 2010 at 2:54 AM, Venkatesh Srinivas
<me@endeavour.zapto.org> wrote:
> Oh, no, it wasn't meant as a defense! It was much more a 'hmm, only two
> hours can produce fairly solid performance gains; perhaps this deserves a
> more serious look'.
>
> -- vs
>
>

Re: [9fans] A little more ado about async Tclunk

[Charles Forsyth]

you're essentially replacing
	f := open(name, ...)
	...
	close(f)

which runs as a sequential process, and subject to the usual rules for sequential
composition, by

	f := open(name, ...)
	...
	spawn clunk(f)

which introduces a race with an invisible anonymous process with no means of synchronisation.

what could possibly go wrong with that?

(actually, it's more complex than spawning a new process, but the added complexity of a set of service processes changes the details but not the existence of the race, and doesn't affect the anonymity.)

the change isn't sufficent to solve the efficiency (latency) problems addressed by Op,
neither is it sufficient for big performance improvements if you're dealing with something you can cache,
nor is it a necessary solution (at least in the form above) for the deadlock problems.

Re: [9fans] A little more ado about async Tclunk

[Bruce Ellis]

no it is not, charles. i rarely disagree with you but the semantics
are preserved, except for changing the behaviour of existing races.

brucee

On Thu, Oct 28, 2010 at 11:12 PM, Charles Forsyth <forsyth@terzarima.net> wrote:
> you're essentially replacing
>        f := open(name, ...)
>        ...
>        close(f)
>
> which runs as a sequential process, and subject to the usual rules for sequential
> composition, by
>
>        f := open(name, ...)
>        ...
>        spawn clunk(f)
>
> which introduces a race with an invisible anonymous process with no means of synchronisation.
>
> what could possibly go wrong with that?
>
> (actually, it's more complex than spawning a new process, but the added complexity of a set of service processes changes the details but not the existence of the race, and doesn't affect the anonymity.)
>
> the change isn't sufficent to solve the efficiency (latency) problems addressed by Op,
> neither is it sufficient for big performance improvements if you're dealing with something you can cache,
> nor is it a necessary solution (at least in the form above) for the deadlock problems.
>
>

Re: [9fans] A little more ado about async Tclunk

[Gorka Guardiola]

On Thu, Oct 28, 2010 at 2:12 PM, Charles Forsyth <forsyth@terzarima.net> wrote:
> you're essentially replacing
>        f := open(name, ...)
>        ...
>        close(f)
>
> which runs as a sequential process, and subject to the usual rules for sequential
> composition, by
>
>        f := open(name, ...)
>        ...
>        spawn clunk(f)
>
> which introduces a race with an invisible anonymous process with no means of synchronisation.
>
>


Wouldn´t a better way be?:

f := 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.

Re: [9fans] A little more ado about async Tclunk

[Gorka Guardiola]

>
> Wouldn´t a better way be?:
>
> f := 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.


-- 
- curiosity sKilled the cat

Re: [9fans] A little more ado about async Tclunk

[erik quanstrom]

> Assuming messages are not reordered.

ah, the easy problems can be taken care of by using 1 clunker
and a clunk channel with a fixed buffer.  i'd like to know
more about charles' correctness concerns.  not that this particular
example is all that useful.  cf. nemo

> My argument is that I'd like the operation to be able to fail in
> general, and to be
> synchronous, so I could get an error status (despite caches being
> placed in the middle).

- erik

Re: [9fans] A little more ado about async Tclunk

[Francisco J Ballesteros]

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 <paurea@gmail.com> wrote:
> On Thu, Oct 28, 2010 at 2:12 PM, Charles Forsyth <forsyth@terzarima.net> wrote:
>> you're essentially replacing
>>        f := open(name, ...)
>>        ...
>>        close(f)
>>
>> which runs as a sequential process, and subject to the usual rules for sequential
>> composition, by
>>
>>        f := open(name, ...)
>>        ...
>>        spawn clunk(f)
>>
>> which introduces a race with an invisible anonymous process with no means of synchronisation.
>>
>>
>
>
> Wouldn´t a better way be?:
>
> f := 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.
>
>

Re: [9fans] A little more ado about async Tclunk

[Eric Van Hensbergen]

On Thu, Oct 28, 2010 at 9:41 AM, Francisco J Ballesteros <nemo@lsub.org> wrote:
> 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.
>

Is that an argument for having the cache layer provide the service for
you?  Apps that care about end-to-end semantics aren't likely to be
going through the cache layer anyways.  Do we need differentiation
between "I don't care" clunks and "I care" clunks?  What's the actual
spread of these in applications?  Am I oversimplifying?  That's quite
possible.

     -eric

Re: [9fans] A little more ado about async Tclunk

[Francisco J Ballesteros]

Be there caches of not, I've found that I want to be able to say
"I'm done with this file, let me know if everything is done and ok".

Of course, if you use 9p with no cache, you know you're done if all writes
worked. If you have a cache, things may change. But either way, if you
can check at
close time you can be happy. if there's no cache, it'll always be ok;
if there is, you
might learn that you couldn't put the file in the server and do as you please.

My argument is that I'd like the operation to be able to fail in
general, and to be
synchronous, so I could get an error status (despite caches being
placed in the middle).

After all, if you don't want to block in clunk you can either defer
your closes or pass them
to another process.

Re: [9fans] A little more ado about async Tclunk

[Nathaniel W Filardo]

[-- Attachment #1: Type: text/plain, Size: 627 bytes --]

On Thu, Oct 28, 2010 at 04:56:02PM +0200, Francisco J Ballesteros wrote:
> Be there caches of not, I've found that I want to be able to say
> "I'm done with this file, let me know if everything is done and ok".

You can, just not by using Tclunk.

> Of course, if you use 9p with no cache, you know you're done if all writes
> worked.

Nowhere in the manual does it say that.  The only protocol-defined way to be
sure that you are coherent is to use Twstat with all arguments NOP.  (FWIW,
this may also be superior to checking that Tclunk did not Rerror because the
fid is still live if Twstat Rerrors.)

--nwf;

[-- Attachment #2: Type: application/pgp-signature, Size: 205 bytes --]

Re: [9fans] A little more ado about async Tclunk

[erik quanstrom]

> Nowhere in the manual does it say that.  The only protocol-defined way to be
> sure that you are coherent is to use Twstat with all arguments NOP.  (FWIW,
> this may also be superior to checking that Tclunk did not Rerror because the
> fid is still live if Twstat Rerrors.)

name 3 in-distribution fileservers that respect this tradition uniformly.

- erik

Re: [9fans] A little more ado about async Tclunk

[Francisco J Ballesteros]

Yes, in general, agree, but this was about clunk usage and
semantics, and I think it's important to have the I'm done message
synchronous when you need that.

Btw, I think you mean Tstat, don't you?
I'm not sure Twstat would work that way in practice.

Re: [9fans] A little more ado about async Tclunk

[Venkatesh Srinivas]

[-- Attachment #1: Type: text/plain, Size: 398 bytes --]

On Thu, Oct 28, 2010 at 11:53 AM, Francisco J Ballesteros <nemo@lsub.org>wrote:

> Yes, in general, agree, but this was about clunk usage and
> semantics, and I think it's important to have the I'm done message
> synchronous when you need that.
>
> Btw, I think you mean Tstat, don't you?
> I'm not sure Twstat would work that way in practice.
>
>
No, that was actually Twstat.

-- vs

[-- Attachment #2: Type: text/html, Size: 682 bytes --]

Re: [9fans] A little more ado about async Tclunk

[Venkatesh Srinivas]

[-- Attachment #1: Type: text/plain, Size: 1073 bytes --]

On Thu, Oct 28, 2010 at 8:12 AM, Charles Forsyth <forsyth@terzarima.net>wrote:

> you're essentially replacing
>        f := open(name, ...)
>        ...
>        close(f)
>
> which runs as a sequential process, and subject to the usual rules for
> sequential
> composition, by
>
>        f := open(name, ...)
>        ...
>        spawn clunk(f)
>
> which introduces a race with an invisible anonymous process with no means
> of synchronisation.
>
> what could possibly go wrong with that?
>
> (actually, it's more complex than spawning a new process, but the added
> complexity of a set of service processes changes the details but not the
> existence of the race, and doesn't affect the anonymity.)
>

Hmm, I don't see the race there; perhaps I'm missing something or being
blind; could you explain?

Also, if that is racy, isn't this at least analogous?

f := Sys->open(name, ...);
... # put f in a cyclic structure
f = nil;
evil_cyclic = nil;
... # wait until an invisible service process closes it, perhaps later?

Thanks,
-- vs

[-- Attachment #2: Type: text/html, Size: 1522 bytes --]

Re: [9fans] A little more ado about async Tclunk

[Charles Forsyth]

>Also, if that is racy, isn't this at least analogous?

i don't think so: that instance is entirely at the discretion of the programmer.
it would be analogous if the text of the program actually contained `spawn clunk(f)',
but i was trying to represent the effects of the rewriting the system would be doing, and that
rewriting (as it has been presented) is built in to the system call.

the race is that there's nothing to say that the clunk completes before the
process continues on to do something more, including some action that depends on the clunk completing,
such as simply repeating the open. that open can fail if the mode or the name
imposes particular constraints; constraints that depend on the order of events as
expressed by the process.

months ago, i did test an example on the system that "just works", by the way,
and it did fail. it often takes a few attempts for it to fail,
because it depends on scheduling (often the system completes the clunk before
returning to the original process), but there's nothing to stop it failing immediately.

Re: [9fans] A little more ado about async Tclunk

[Venkatesh Srinivas]

[-- Attachment #1: Type: text/plain, Size: 1202 bytes --]

On Thu, Oct 28, 2010 at 4:18 PM, Charles Forsyth <forsyth@terzarima.net>wrote:

> the race is that there's nothing to say that the clunk completes before the
> process continues on to do something more, including some action that
> depends on the clunk completing,
> such as simply repeating the open. that open can fail if the mode or the
> name
> imposes particular constraints; constraints that depend on the order of
> events as
> expressed by the process.
>

Of course, we don't want the process to wait.

On a 'decent' file server, TClunk doesn't do anything that a process would
have to wait for, except invalidate the FID; (I exclude ORCLOSE and OEXCL
files here). Guarding this with MCACHE means that there was already a
statement from the user "I think that this file server is a decent
character.". You can definitely write file servers on which TClunk does
things -- ones in which the right combination of opens and clunks fires the
missiles, for example. This is not for those file servers.

On a decent server, since clunk cannot fail and won't launch the missiles,
you can't really do anything that would depend on the result anyway...

Seem reasonable?
-- vs

[-- Attachment #2: Type: text/html, Size: 1583 bytes --]

Re: [9fans] A little more ado about async Tclunk

[Nemo]

[-- Attachment #1: Type: text/plain, Size: 1403 bytes --]

i have decent servers that wait for clunk to operate on written data once it's complete. all octopus spoolers do that. 

On Oct 28, 2010, at 10:32 PM, Venkatesh Srinivas <me@acm.jhu.edu> wrote:

> On Thu, Oct 28, 2010 at 4:18 PM, Charles Forsyth <forsyth@terzarima.net> wrote:
> the race is that there's nothing to say that the clunk completes before the
> process continues on to do something more, including some action that depends on the clunk completing,
> such as simply repeating the open. that open can fail if the mode or the name
> imposes particular constraints; constraints that depend on the order of events as
> expressed by the process.
> 
> Of course, we don't want the process to wait. 
> 
> On a 'decent' file server, TClunk doesn't do anything that a process would have to wait for, except invalidate the FID; (I exclude ORCLOSE and OEXCL files here). Guarding this with MCACHE means that there was already a statement from the user "I think that this file server is a decent character.". You can definitely write file servers on which TClunk does things -- ones in which the right combination of opens and clunks fires the missiles, for example. This is not for those file servers. 
> 
> On a decent server, since clunk cannot fail and won't launch the missiles, you can't really do anything that would depend on the result anyway...
> 
> Seem reasonable?
> -- vs

[-- Attachment #2: Type: text/html, Size: 1975 bytes --]

Re: [9fans] A little more ado about async Tclunk

[Venkatesh Srinivas]

[-- Attachment #1: Type: text/plain, Size: 720 bytes --]

On Thu, Oct 28, 2010 at 4:55 PM, Nemo <nemo.mbox@gmail.com> wrote:

> i have decent servers that wait for clunk to operate on written data once
> it's complete. all octopus spoolers do that.
>
>
Heh; when I wrote 'decent', I was recalling the old proposed QTDECENT qid
type. I didn't mean to impugn your file servers; they're probably very nice
people and if I met them, I'd should buy them a drink.

Let's try to define 'decent' for this thread -- a decent fileserver is one
on which close()s do not have any client-visible or semantic effect other
than to invalidate the Fid that was passed to them. Lets see how many file
servers we can think of that are 'decent': fossil, kfs, ken, memfs, ...

-- vs

[-- Attachment #2: Type: text/html, Size: 1147 bytes --]

Re: [9fans] A little more ado about async Tclunk

[Francisco J Ballesteros]

Yep. I did propose QTDECENT, and those files would have QTDECENT
set. That's what I mean.

I don't agree with your definition for decency. It's indecent [kidding ;)]

On Thu, Oct 28, 2010 at 11:22 PM, Venkatesh Srinivas
<me@endeavour.zapto.org> wrote:
> On Thu, Oct 28, 2010 at 4:55 PM, Nemo <nemo.mbox@gmail.com> wrote:
>>
>> i have decent servers that wait for clunk to operate on written data once
>> it's complete. all octopus spoolers do that.
>
> Heh; when I wrote 'decent', I was recalling the old proposed QTDECENT qid
> type. I didn't mean to impugn your file servers; they're probably very nice
> people and if I met them, I'd should buy them a drink.
>
> Let's try to define 'decent' for this thread -- a decent fileserver is one
> on which close()s do not have any client-visible or semantic effect other
> than to invalidate the Fid that was passed to them. Lets see how many file
> servers we can think of that are 'decent': fossil, kfs, ken, memfs, ...
>
> -- vs
>

Re: [9fans] A little more ado about async Tclunk

[Gorka Guardiola]

On Thu, Oct 28, 2010 at 10:18 PM, Charles Forsyth <forsyth@terzarima.net> wrote:
>
> the race is that there's nothing to say that the clunk completes before the
> process continues on to do something more, including some action that depends on the clunk completing,
> such as simply repeating the open. that open can fail if the mode or the name
> imposes particular constraints; constraints that depend on the order of events as
> expressed by the process.

What you are saying is that the problem could be something like:

-> Tclunk
(do not wait for response)
-> Topen (the file is exclusive)

Then somehow in the server, Tclunk and Topen are reordered because
they are managed
by different threads and Topen gets an error because the file is already opened.

This is a problem, I agree.

> On Oct 28, 2010, at 10:32 PM, Venkatesh Srinivas <me@acm.jhu.edu> wrote:
> On a decent server, since clunk cannot fail and won't launch the missiles, you can't really do anything that would depend on the result anyway.

Tclunk may be a good time to commit to disk or do other unmissile like thing.
You can switch to another cache after waiting for the Rclunk, for example.

Decent or not indecent I am more and more conviced after this thread that
Tclunk should be synchronous. Even in decent files Tclunk can  have
some side effects.

Re: [9fans] A little more ado about async Tclunk

[Bruce Ellis]

No! Open on an exclusive file has the same races. No problems on
Froggie .. no servers with clunk semantics. The first I encountered
was Bosch's video streamer. Nemo obviously has concerns.

Catch a run.

brucee

On Fri, Oct 29, 2010 at 10:51 AM, Gorka Guardiola <paurea@gmail.com> wrote:
> On Thu, Oct 28, 2010 at 10:18 PM, Charles Forsyth <forsyth@terzarima.net> wrote:
>>
>> the race is that there's nothing to say that the clunk completes before the
>> process continues on to do something more, including some action that depends on the clunk completing,
>> such as simply repeating the open. that open can fail if the mode or the name
>> imposes particular constraints; constraints that depend on the order of events as
>> expressed by the process.
>
> What you are saying is that the problem could be something like:
>
> -> Tclunk
> (do not wait for response)
> -> Topen (the file is exclusive)
>
> Then somehow in the server, Tclunk and Topen are reordered because
> they are managed
> by different threads and Topen gets an error because the file is already opened.
>
> This is a problem, I agree.
>
>> On Oct 28, 2010, at 10:32 PM, Venkatesh Srinivas <me@acm.jhu.edu> wrote:
>> On a decent server, since clunk cannot fail and won't launch the missiles, you can't really do anything that would depend on the result anyway.
>
> Tclunk may be a good time to commit to disk or do other unmissile like thing.
> You can switch to another cache after waiting for the Rclunk, for example.
>
> Decent or not indecent I am more and more conviced after this thread that
> Tclunk should be synchronous. Even in decent files Tclunk can  have
> some side effects.
>
>

Re: [9fans] A little more ado about async Tclunk

[Gorka Guardiola]

On Fri, Oct 29, 2010 at 7:37 AM, Bruce Ellis <bruce.ellis@gmail.com> wrote:
> No! Open on an exclusive file has the same races. No problems on

I said I agree it is a problem. Yes, there is a race... Froggie?
A lily-white duck come and swallowed him up,..

Re: [9fans] A little more ado about async Tclunk

[Bruce Ellis]

my froggie has been running for four years 24/7. if you haven't read
the BLTJ then styx runs over the PCI ... 4  ixp1200s. asynch clunks.
the only problem is it's 10 times quicker.

the only server that i saw at the labs that had Rclunk semantics was
pb's video magic which i i didn't need.  nemo throws a spaniard in the
works. ozi2 aka casella is not ref counted but swiftly sweeps.

brucee

On Fri, Oct 29, 2010 at 6:44 PM, Gorka Guardiola <paurea@gmail.com> wrote:
> On Fri, Oct 29, 2010 at 7:37 AM, Bruce Ellis <bruce.ellis@gmail.com> wrote:
>> No! Open on an exclusive file has the same races. No problems on
>
> I said I agree it is a problem. Yes, there is a race... Froggie?
> A lily-white duck come and swallowed him up,..
>
>

Re: [9fans] A little more ado about async Tclunk

[Charles Forsyth]

>What you are saying is that the problem could be something like:

>-> Tclunk
>(do not wait for response)
>-> Topen (the file is exclusive)

no, because what actually happens is closer to
	A: Topen
	...
	queue request to *another process* to send Tclunk
	...
	A: Topen

leading to either case 1
	A: Topen
	B: Tclunk
	A: Topen

or case 2
	A: Topen
	A: Topen
	B: Tclunk

depending on the scheduling of the two processes A and B

introducing that other process introduces a new race, that simply did not exist before, because
that other process didn't exist before. you always got case 1.

and indeed, with the test i ran on the modified system usually it gets case 1
because of timing, but eventually a case 2 shows up and the second open fails.

Re: [9fans] A little more ado about async Tclunk

[Bruce Ellis]

i don't believe that is possible in my implementation. will check.

brucee

On Fri, Oct 29, 2010 at 8:01 PM, Charles Forsyth <forsyth@terzarima.net> wrote:
>>What you are saying is that the problem could be something like:
>
>>-> Tclunk
>>(do not wait for response)
>>-> Topen (the file is exclusive)
>
> no, because what actually happens is closer to
>        A: Topen
>        ...
>        queue request to *another process* to send Tclunk
>        ...
>        A: Topen
>
> leading to either case 1
>        A: Topen
>        B: Tclunk
>        A: Topen
>
> or case 2
>        A: Topen
>        A: Topen
>        B: Tclunk
>
> depending on the scheduling of the two processes A and B
>
> introducing that other process introduces a new race, that simply did not exist before, because
> that other process didn't exist before. you always got case 1.
>
> and indeed, with the test i ran on the modified system usually it gets case 1
> because of timing, but eventually a case 2 shows up and the second open fails.
>
>

Re: [9fans] A little more ado about async Tclunk

[Charles Forsyth]

>i don't believe that is possible in my implementation. will check.

it was your implementation i was testing.

Re: [9fans] A little more ado about async Tclunk

[Gorka Guardiola]

On Fri, Oct 29, 2010 at 11:01 AM, Charles Forsyth <forsyth@terzarima.net> wrote:
>>What you are saying is that the problem could be something like:
>
>>-> Tclunk
>>(do not wait for response)
>>-> Topen (the file is exclusive)
>
> no, because what actually happens is closer to
>        A: Topen
>        ...
>        queue request to *another process* to send Tclunk
>        ...
>        A: Topen
>
> leading to either case 1
>        A: Topen
>        B: Tclunk
>        A: Topen
>
> or case 2
>        A: Topen
>        A: Topen
>        B: Tclunk
>
> depending on the scheduling of the two processes A and B
>
> introducing that other process introduces a new race, that simply did not exist before, because
> that other process didn't exist before. you always got case 1.
>
> and indeed, with the test i ran on the modified system usually it gets case 1
> because of timing, but eventually a case 2 shows up and the second open fails.
>
>

That is why I said, (my second message in the thread) that at least
you should send the Tclunks synchronously.
Meaning the close system call sends the Tclunk
and then fires another thread/writes down in a list for another thread
for the fid to be recollected when the
answer comes asynchronously.
This prevents the fid being reused and simultaneously tries
to keep the operations in the order the client intended.
Still there are no guarantees, because the
messages can be reordered in the server but...
Still, it does not work in general (the server...) and I thought it was not
profitable enough to be worth the hassle, but then...

> my froggie has been running for four years 24/7. if you haven't read
> the BLTJ then styx runs over the PCI ... 4  ixp1200s. asynch clunks.
> the only problem is it's 10 times quicker.

I haven´t read the Journal, I thought it was referring to the Dylan´s song
putting froggie as an archetype of decency. You are talking about this?:
http://onlinelibrary.wiley.com/doi/10.1002/bltj.1/pdf

Do you do completely asynch clunks or just the wait for the response?.
10 times?, that is some latency. Can you break up exactly where the gain
comes from?.

G.

Re: [9fans] A little more ado about async Tclunk

[Bruce Ellis]

right journal. i'll do some unusual tests and report on the results.

wing-commander has to awake early to attend his mother's 80th birthday party.

back to you on this one.

brucee

On Fri, Oct 29, 2010 at 8:45 PM, Gorka Guardiola <paurea@gmail.com> wrote:
> On Fri, Oct 29, 2010 at 11:01 AM, Charles Forsyth <forsyth@terzarima.net> wrote:
>>>What you are saying is that the problem could be something like:
>>
>>>-> Tclunk
>>>(do not wait for response)
>>>-> Topen (the file is exclusive)
>>
>> no, because what actually happens is closer to
>>        A: Topen
>>        ...
>>        queue request to *another process* to send Tclunk
>>        ...
>>        A: Topen
>>
>> leading to either case 1
>>        A: Topen
>>        B: Tclunk
>>        A: Topen
>>
>> or case 2
>>        A: Topen
>>        A: Topen
>>        B: Tclunk
>>
>> depending on the scheduling of the two processes A and B
>>
>> introducing that other process introduces a new race, that simply did not exist before, because
>> that other process didn't exist before. you always got case 1.
>>
>> and indeed, with the test i ran on the modified system usually it gets case 1
>> because of timing, but eventually a case 2 shows up and the second open fails.
>>
>>
>
> That is why I said, (my second message in the thread) that at least
> you should send the Tclunks synchronously.
> Meaning the close system call sends the Tclunk
> and then fires another thread/writes down in a list for another thread
> for the fid to be recollected when the
> answer comes asynchronously.
> This prevents the fid being reused and simultaneously tries
> to keep the operations in the order the client intended.
> Still there are no guarantees, because the
> messages can be reordered in the server but...
> Still, it does not work in general (the server...) and I thought it was not
> profitable enough to be worth the hassle, but then...
>
>> my froggie has been running for four years 24/7. if you haven't read
>> the BLTJ then styx runs over the PCI ... 4  ixp1200s. asynch clunks.
>> the only problem is it's 10 times quicker.
>
> I haven´t read the Journal, I thought it was referring to the Dylan´s song
> putting froggie as an archetype of decency. You are talking about this?:
> http://onlinelibrary.wiley.com/doi/10.1002/bltj.1/pdf
>
> Do you do completely asynch clunks or just the wait for the response?.
> 10 times?, that is some latency. Can you break up exactly where the gain
> comes from?.
>
> G.
>
>

Re: [9fans] A little more ado about async Tclunk

[Charles Forsyth]

>Do you do completely asynch clunks or just the wait for the response?.

it uses `completely' async clunks, which is why it can be broken.

having the original process send the Tclunk and not wait
for the Rclunk is different. i think it was mentioned last time this
matter came up, and that's probably why i didn't pursue this discussion
further then, since that change is less of a problem. (at least, if you don't mind
close not returning an error from the clunk, but since the current implementations
suppress errors from clunk, it's a trickier position to sustain.)

Re: [9fans] A little more ado about async Tclunk

[Venkatesh Srinivas]

[-- Attachment #1: Type: text/plain, Size: 1251 bytes --]

On Fri, Oct 29, 2010 at 12:01 PM, Charles Forsyth <forsyth@terzarima.net>wrote:

> >Do you do completely asynch clunks or just the wait for the response?.
>
> it uses `completely' async clunks, which is why it can be broken.
>
> having the original process send the Tclunk and not wait
> for the Rclunk is different. i think it was mentioned last time this
> matter came up, and that's probably why i didn't pursue this discussion
> further then, since that change is less of a problem. (at least, if you
> don't mind
> close not returning an error from the clunk, but since the current
> implementations
> suppress errors from clunk, it's a trickier position to sustain.)
>
>
I think that this is a fine approach as well -- the vast majority of the
performance improvement is in eliminating the wait for the Rclunk, not in
the asynchronous issue. I didn't use this approach here not because I wanted
to issue the clunk out-of-line, but because it was harder to code (I'd have
needed to split devmnt's mountio()).

This was actually the approach Wes and I did last year when commenting on
the desirability of asynchronous clunks, in a purely "user mode" process.
The performance gains were very similar to this work.

-- vs

[-- Attachment #2: Type: text/html, Size: 1603 bytes --]

Re: [9fans] A little more ado about async Tclunk

[roger peppe]

On 29 October 2010 17:01, Charles Forsyth <forsyth@terzarima.net> wrote:
>>Do you do completely asynch clunks or just the wait for the response?.
>
> it uses `completely' async clunks, which is why it can be broken.
>
> having the original process send the Tclunk and not wait
> for the Rclunk is different.

for some reason, though i didn't look at the diffs, i thought
that's what this patch did.

even sending Tclunk synchronously is still problematic in quite a few scenarios,
for the reasons i outlined above.

Re: [9fans] A little more ado about async Tclunk

[Bruce Ellis]

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.

brucee

On Sat, Oct 30, 2010 at 3:02 AM, roger peppe <rogpeppe@gmail.com> wrote:
> On 29 October 2010 17:01, Charles Forsyth <forsyth@terzarima.net> wrote:
>>>Do you do completely asynch clunks or just the wait for the response?.
>>
>> it uses `completely' async clunks, which is why it can be broken.
>>
>> having the original process send the Tclunk and not wait
>> for the Rclunk is different.
>
> for some reason, though i didn't look at the diffs, i thought
> that's what this patch did.
>
> even sending Tclunk synchronously is still problematic in quite a few scenarios,
> for the reasons i outlined above.
>
>

Re: [9fans] A little more ado about async Tclunk

[roger peppe]

On 29 October 2010 17:17, Bruce Ellis <bruce.ellis@gmail.com> wrote:
> 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.

if deadlock is the issue, isn't it solved just as well
by asynchronously receiving the Rclunk as by processing
the whole clunk message asychronously?

Re: [9fans] A little more ado about async Tclunk

[Charles Forsyth]

>having the original process send the Tclunk and not wait
>for the Rclunk is different.

ah. having thought about it, i see it's different only in the case of
one process. it isn't different if you have several processes that are
trying to co-operate in an allowed way: failing to let the issuing
process know when the operation has actually been completed prevents
it from communicating that to another process, but on the other hand,
with the existing constructions, it can't find out.

Re: [9fans] A little more ado about async Tclunk

[Eric Van Hensbergen]

On Fri, Oct 29, 2010 at 4:01 AM, Charles Forsyth <forsyth@terzarima.net> wrote:
>>What you are saying is that the problem could be something like:
>
>>-> Tclunk
>>(do not wait for response)
>>-> Topen (the file is exclusive)
>
> no, because what actually happens is closer to
>        A: Topen
>        ...
>        queue request to *another process* to send Tclunk
>        ...
>        A: Topen
>
> leading to either case 1
>        A: Topen
>        B: Tclunk
>        A: Topen
>
> or case 2
>        A: Topen
>        A: Topen
>        B: Tclunk
>
> depending on the scheduling of the two processes A and B
>
> introducing that other process introduces a new race, that simply did not exist before, because
> that other process didn't exist before. you always got case 1.
>
> and indeed, with the test i ran on the modified system usually it gets case 1
> because of timing, but eventually a case 2 shows up and the second open fails.
>

Just to make sure I understand things correctly, where does this mess
things up with standard (as opposed to synthetic) file systems?
ORCLOSE? OEXCL? Or is the primary concern the data flushing effect
implicit in clunk?  I'm inclined to agree with what I think gorka's
stance is, send the clunk, but have an option to asynchronously gather
the response (or make that the default and the option would be to
synchronously wait for the response (waitfd(2)?)  That would allow
apps that really care about the data sync semantics (or oexcl, etc.)
to make sure things have proceeded as planned, but wouldn't hold up
the 99% of other apps that don't give a care.

I guess my concern is that the always synchronous clunk for race-less
semantics is simple, but if we really are giving up a big chunk of
performance for the majority of uses and users, then it begs
re-evaluation of the approach.

       -eric

Re: [9fans] A little more ado about async Tclunk

[roger peppe]

On 29 October 2010 15:14, Eric Van Hensbergen <ericvh@gmail.com> wrote:
> Just to make sure I understand things correctly, where does this mess
> things up with standard (as opposed to synthetic) file systems?

i think that part of the problem is that plan 9 makes no distinction
between "standard" and "synthetic" file systems.

perhaps if there was, then optimisations like this could
work a little less haphazardly.

Re: [9fans] A little more ado about async Tclunk

[erik quanstrom]

> i think that part of the problem is that plan 9 makes no distinction
> between "standard" and "synthetic" file systems.
>
> perhaps if there was, then optimisations like this could
> work a little less haphazardly.

what's a reasonable definition of "standard"?

- erik

Re: [9fans] A little more ado about async Tclunk

[Eric Van Hensbergen]

On Fri, Oct 29, 2010 at 10:21 AM, roger peppe <rogpeppe@gmail.com> wrote:
> On 29 October 2010 15:14, Eric Van Hensbergen <ericvh@gmail.com> wrote:
>> Just to make sure I understand things correctly, where does this mess
>> things up with standard (as opposed to synthetic) file systems?
>
> i think that part of the problem is that plan 9 makes no distinction
> between "standard" and "synthetic" file systems.
>
> perhaps if there was, then optimisations like this could
> work a little less haphazardly.
>

Yeah, that was sort of a baseline assumption for me.  Most of the
synthetic file servers are susceptible to problems from such short
cuts (although as Brucee points out, that depends on the short-cut and
the file server).  However, in many cases those servers don't need
particularly high performance.  It would be nice to have a
system/protocol capable of satisfying both design points.  Perhaps
pi-p could provide such flexibility, perhaps it would need to be
something else.

      -eric

Re: [9fans] A little more ado about async Tclunk

[Charles Forsyth]

> things up with standard (as opposed to synthetic) file systems?

why should a "synthetic" file system (actually they are all synthetic, i think)
be considered not "standard"? i thought file systems were the common currency in the system.

Re: [9fans] A little more ado about async Tclunk

[Eric Van Hensbergen]

On Fri, Oct 29, 2010 at 10:49 AM, Charles Forsyth <forsyth@terzarima.net> wrote:
>> things up with standard (as opposed to synthetic) file systems?
>
> why should a "synthetic" file system (actually they are all synthetic, i think)
> be considered not "standard"? i thought file systems were the common currency in the system.
>

correct, it seems to have caused confusion all around.  Perhaps
s/standard/disk/g

      -eric

Re: [9fans] A little more ado about async Tclunk

[Bruce Ellis]

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

On Sat, Oct 30, 2010 at 2:50 AM, Eric Van Hensbergen <ericvh@gmail.com> wrote:
> On Fri, Oct 29, 2010 at 10:49 AM, Charles Forsyth <forsyth@terzarima.net> wrote:
>>> things up with standard (as opposed to synthetic) file systems?
>>
>> why should a "synthetic" file system (actually they are all synthetic, i think)
>> be considered not "standard"? i thought file systems were the common currency in the system.
>>
>
> correct, it seems to have caused confusion all around.  Perhaps
> s/standard/disk/g
>
>      -eric
>
>

Re: [9fans] A little more ado about async Tclunk

[Venkatesh Srinivas]

[-- Attachment #1: Type: text/plain, Size: 2653 bytes --]

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
>

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

[-- Attachment #2: Type: text/html, Size: 3471 bytes --]

Re: [9fans] A little more ado about async Tclunk

[erik quanstrom]

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

unfortunately, unless you are talking about archival storage (e.g., /n/dump),
i think the difference between a "decent" file and a ctl file starts to seem slippery.
unless a file is exclusive open it's hard to be sure that a file won't change
underneath you.

- erik

Re: [9fans] A little more ado about async Tclunk

[David Leimbach]

[-- Attachment #1: Type: text/plain, Size: 961 bytes --]

On Fri, Oct 29, 2010 at 8:49 AM, Charles Forsyth <forsyth@terzarima.net>wrote:

> > things up with standard (as opposed to synthetic) file systems?
>
> why should a "synthetic" file system (actually they are all synthetic, i
> think)
> be considered not "standard"? i thought file systems were the common
> currency in the system.
>
>

All file systems are synthetic, some are backed by disk blocks, or other
goo.  File systems are nothing more than a namespace abstraction on X, where
you get to decide what X is if you're implementing one.

This is what I've been trying to communicate to my software development
teams last year, and they very nearly got it :-).

I think functional programming or at least category theory gets you into
these upper level abstract ways of thinking that help with making such
nonsense into sense.  (I'm not sure that last sentence really parses, but
since I've lost my backspace key, there it is)

Dave

[-- Attachment #2: Type: text/html, Size: 1347 bytes --]

Re: [9fans] A little more ado about async Tclunk

[Charles Forsyth]

>I think functional programming or at least category theory gets you into
>these upper level abstract ways of thinking

uh oh. is there an analogy to Godwin's Law for mentioning category theory?

Re: [9fans] A little more ado about async Tclunk

[David Leimbach]

[-- Attachment #1: Type: text/plain, Size: 559 bytes --]

On Fri, Oct 29, 2010 at 10:13 AM, Charles Forsyth <forsyth@terzarima.net>wrote:

> >I think functional programming or at least category theory gets you into
> >these upper level abstract ways of thinking
>
> uh oh. is there an analogy to Godwin's Law for mentioning category theory?
>
> I hope not... I'm merely trying to say the act of moving a problem between
languages can shed some light from time to time.

Category Theory really doesn't say too much in general, but oddly enough it
applies nicely to computer science.  What's that mean? :-)

[-- Attachment #2: Type: text/html, Size: 877 bytes --]

Re: [9fans] A little more ado about async Tclunk

[erik quanstrom]

> Category Theory really doesn't say too much in general, but oddly enough it
> applies nicely to computer science.  What's that mean? :-)

that they're both abstract nonsense.

- erik

Re: [9fans] A little more ado about async Tclunk

[Bruce Ellis]

who said deadlock. it's an easily reproducible situation. rattle the
cage is not a solution.

brucee

On Sat, Oct 30, 2010 at 4:26 AM, erik quanstrom <quanstro@quanstro.net> wrote:
>> Category Theory really doesn't say too much in general, but oddly enough it
>> applies nicely to computer science.  What's that mean? :-)
>
> that they're both abstract nonsense.
>
> - erik
>
>

Re: [9fans] A little more ado about async Tclunk

[roger peppe]

On 29 October 2010 18:47, Bruce Ellis <bruce.ellis@gmail.com> wrote:
> who said deadlock. it's an easily reproducible situation. rattle the
> cage is not a solution.

sorry then, i misunderstood you. what else did you mean by "deadly embrace"?

Re: [9fans] A little more ado about async Tclunk

[Bruce Ellis]

back to school for roger

On Sat, Oct 30, 2010 at 6:33 AM, roger peppe <rogpeppe@gmail.com> wrote:
> On 29 October 2010 18:47, Bruce Ellis <bruce.ellis@gmail.com> wrote:
>> who said deadlock. it's an easily reproducible situation. rattle the
>> cage is not a solution.
>
> sorry then, i misunderstood you. what else did you mean by "deadly embrace"?
>
>

Re: [9fans] A little more ado about async Tclunk

[Gorka Guardiola]

On Oct 29, 2010, at 10:27 PM, Bruce Ellis <bruce.ellis@gmail.com> wrote:

> back to school for roger
> 
> On Sat, Oct 30, 2010 at 6:33 AM, roger peppe <rogpeppe@gmail.com> wrote:
>> On 29 October 2010 18:47, Bruce Ellis <bruce.ellis@gmail.com> wrote:
>>> who said deadlock. it's an easily reproducible situation. rattle the
>>> cage is not a solution.
>> 
>> sorry then, i misunderstood you. what else did you mean by "deadly embrace"?
>> 
>> 
> 

I need to go back to school with him too.

http://www.olc.edu/~cdelong/jargon-4.4.7/jargon-4.4.7/html/D/deadly-embrace.html

Unless it is again some obscure reference...

Re: [9fans] A little more ado about async Tclunk

[Bruce Ellis]

that definition is wrong!

On Sat, Oct 30, 2010 at 7:41 AM, Gorka Guardiola <paurea@gmail.com> wrote:
>
> On Oct 29, 2010, at 10:27 PM, Bruce Ellis <bruce.ellis@gmail.com> wrote:
>
>> back to school for roger
>>
>> On Sat, Oct 30, 2010 at 6:33 AM, roger peppe <rogpeppe@gmail.com> wrote:
>>> On 29 October 2010 18:47, Bruce Ellis <bruce.ellis@gmail.com> wrote:
>>>> who said deadlock. it's an easily reproducible situation. rattle the
>>>> cage is not a solution.
>>>
>>> sorry then, i misunderstood you. what else did you mean by "deadly embrace"?
>>>
>>>
>>
>
> I need to go back to school with him too.
>
> http://www.olc.edu/~cdelong/jargon-4.4.7/jargon-4.4.7/html/D/deadly-embrace.html
>
> Unless it is again some obscure reference...
>

Re: [9fans] A little more ado about async Tclunk

[Bakul Shah]

See EWD108 "Een algorithme ter voorkoming van de dodelijke
omarming." (An algorithm to avoid the deadly embrace.) in
which Dijkstra describes his Bankers algorithm.  1965 or
earlier. Of course, you may be looking at deadly embrace
from a different point of view.

On Sat, 30 Oct 2010 07:44:58 +1100 Bruce Ellis <bruce.ellis@gmail.com>  wrote:
> that definition is wrong!
>
> On Sat, Oct 30, 2010 at 7:41 AM, Gorka Guardiola <paurea@gmail.com> wrote:
> >
> > On Oct 29, 2010, at 10:27 PM, Bruce Ellis <bruce.ellis@gmail.com> wrote:
> >
> >> back to school for roger
> >>
> >> On Sat, Oct 30, 2010 at 6:33 AM, roger peppe <rogpeppe@gmail.com> wrote:
> >>> On 29 October 2010 18:47, Bruce Ellis <bruce.ellis@gmail.com> wrote:
> >>>> who said deadlock. it's an easily reproducible situation. rattle the
> >>>> cage is not a solution.
> >>>
> >>> sorry then, i misunderstood you. what else did you mean by "deadly embrac
> e"?
> >>>
> >>>
> >>
> >
> > I need to go back to school with him too.
> >
> > http://www.olc.edu/~cdelong/jargon-4.4.7/jargon-4.4.7/html/D/deadly-embrace
> .html
> >
> > Unless it is again some obscure reference...
> >
>

Re: [9fans] A little more ado about async Tclunk

[roger peppe]

On 29 October 2010 21:44, Bruce Ellis <bruce.ellis@gmail.com> wrote:
> that definition is wrong!

so point us to the right one then.

Re: [9fans] A little more ado about async Tclunk

[Bruce Ellis]

grab a book by hoare or morgan.

brucee

On Sat, Oct 30, 2010 at 9:39 AM, roger peppe <rogpeppe@gmail.com> wrote:
> On 29 October 2010 21:44, Bruce Ellis <bruce.ellis@gmail.com> wrote:
>> that definition is wrong!
>
> so point us to the right one then.
>
>

Re: [9fans] A little more ado about async Tclunk

[roger peppe]

the only book by hoare i've got (CSP) doesn't mention a deadly embrace.

On 29 October 2010 23:43, Bruce Ellis <bruce.ellis@gmail.com> wrote:
> grab a book by hoare or morgan.
>
> brucee
>
> On Sat, Oct 30, 2010 at 9:39 AM, roger peppe <rogpeppe@gmail.com> wrote:
>> On 29 October 2010 21:44, Bruce Ellis <bruce.ellis@gmail.com> wrote:
>>> that definition is wrong!
>>
>> so point us to the right one then.
>>
>>
>
>

Re: [9fans] A little more ado about async Tclunk

[Bruce Ellis]

well you need more books.

On Sat, Oct 30, 2010 at 10:07 AM, roger peppe <rogpeppe@gmail.com> wrote:
> the only book by hoare i've got (CSP) doesn't mention a deadly embrace.
>
> On 29 October 2010 23:43, Bruce Ellis <bruce.ellis@gmail.com> wrote:
>> grab a book by hoare or morgan.
>>
>> brucee
>>
>> On Sat, Oct 30, 2010 at 9:39 AM, roger peppe <rogpeppe@gmail.com> wrote:
>>> On 29 October 2010 21:44, Bruce Ellis <bruce.ellis@gmail.com> wrote:
>>>> that definition is wrong!
>>>
>>> so point us to the right one then.
>>>
>>>
>>
>>
>
>

Re: [9fans] A little more ado about async Tclunk

[Nemo]

let's call it rumba and go on.


On Oct 30, 2010, at 1:28 AM, Bruce Ellis <bruce.ellis@gmail.com> wrote:

> well you need more books.
>
> On Sat, Oct 30, 2010 at 10:07 AM, roger peppe <rogpeppe@gmail.com> wrote:
>> the only book by hoare i've got (CSP) doesn't mention a deadly embrace.
>>
>> On 29 October 2010 23:43, Bruce Ellis <bruce.ellis@gmail.com> wrote:
>>> grab a book by hoare or morgan.
>>>
>>> brucee
>>>
>>> On Sat, Oct 30, 2010 at 9:39 AM, roger peppe <rogpeppe@gmail.com> wrote:
>>>> On 29 October 2010 21:44, Bruce Ellis <bruce.ellis@gmail.com> wrote:
>>>>> that definition is wrong!
>>>>
>>>> so point us to the right one then.
>>>>
>>>>
>>>
>>>
>>
>>
>

Re: [9fans] A little more ado about async Tclunk

[Bruce Ellis]

good call. i just hate misinformation. if there is any more misleading
trash i will gladly give the offender Morgan's phone number.

brucee

On Sat, Oct 30, 2010 at 8:08 PM, Nemo <nemo.mbox@gmail.com> wrote:
> let's call it rumba and go on.
>
>
> On Oct 30, 2010, at 1:28 AM, Bruce Ellis <bruce.ellis@gmail.com> wrote:
>
>> well you need more books.
>>
>> On Sat, Oct 30, 2010 at 10:07 AM, roger peppe <rogpeppe@gmail.com> wrote:
>>> the only book by hoare i've got (CSP) doesn't mention a deadly embrace.
>>>
>>> On 29 October 2010 23:43, Bruce Ellis <bruce.ellis@gmail.com> wrote:
>>>> grab a book by hoare or morgan.
>>>>
>>>> brucee
>>>>
>>>> On Sat, Oct 30, 2010 at 9:39 AM, roger peppe <rogpeppe@gmail.com> wrote:
>>>>> On 29 October 2010 21:44, Bruce Ellis <bruce.ellis@gmail.com> wrote:
>>>>>> that definition is wrong!
>>>>>
>>>>> so point us to the right one then.
>>>>>
>>>>>
>>>>
>>>>
>>>
>>>
>>
>
>

Re: [9fans] A little more ado about async Tclunk

[roger peppe]

[-- Attachment #1: Type: text/plain, Size: 514 bytes --]

if you hate misinformation, why not provide some correct information to
counter it? i'd hazard a guess that nobody other than you in this thread
knows what you mean by "deadly embrace".

On 31 Oct 2010 05:47, "Bruce Ellis" <bruce.ellis@gmail.com> wrote:

good call. i just hate misinformation. if there is any more misleading
trash i will gladly give the offender Morgan's phone number.

brucee


On Sat, Oct 30, 2010 at 8:08 PM, Nemo <nemo.mbox@gmail.com> wrote:
> let's call it rumba and go on....

[-- Attachment #2: Type: text/html, Size: 752 bytes --]

Re: [9fans] A little more ado about async Tclunk

[Bruce Ellis]

oh shut up. learn.

you want Morgan's phone number?

brucee

On Sun, Oct 31, 2010 at 7:52 PM, roger peppe <rogpeppe@gmail.com> wrote:
> if you hate misinformation, why not provide some correct information to
> counter it? i'd hazard a guess that nobody other than you in this thread
> knows what you mean by "deadly embrace".
>
> On 31 Oct 2010 05:47, "Bruce Ellis" <bruce.ellis@gmail.com> wrote:
>
> good call. i just hate misinformation. if there is any more misleading
> trash i will gladly give the offender Morgan's phone number.
>
> brucee
>
> On Sat, Oct 30, 2010 at 8:08 PM, Nemo <nemo.mbox@gmail.com> wrote:
>> let's call it rumba and go on....

Re: [9fans] A little more ado about async Tclunk

[fgergo]

I believe livelock can happen.

On 10/31/10, Bruce Ellis <bruce.ellis@gmail.com> wrote:
> oh shut up. learn.
>
> you want Morgan's phone number?
>
> brucee
>
> On Sun, Oct 31, 2010 at 7:52 PM, roger peppe <rogpeppe@gmail.com> wrote:
>> if you hate misinformation, why not provide some correct information to
>> counter it? i'd hazard a guess that nobody other than you in this thread
>> knows what you mean by "deadly embrace".
>>
>> On 31 Oct 2010 05:47, "Bruce Ellis" <bruce.ellis@gmail.com> wrote:
>>
>> good call. i just hate misinformation. if there is any more misleading
>> trash i will gladly give the offender Morgan's phone number.
>>
>> brucee
>>
>> On Sat, Oct 30, 2010 at 8:08 PM, Nemo <nemo.mbox@gmail.com> wrote:
>>> let's call it rumba and go on....
>
>

Re: [9fans] A little more ado about async Tclunk

[fgergo]

Or not. Sorry for the noise.

On 10/31/10, fgergo@gmail.com <fgergo@gmail.com> wrote:
> I believe livelock can happen.
>
> On 10/31/10, Bruce Ellis <bruce.ellis@gmail.com> wrote:
>> oh shut up. learn.
>>
>> you want Morgan's phone number?
>>
>> brucee
>>
>> On Sun, Oct 31, 2010 at 7:52 PM, roger peppe <rogpeppe@gmail.com> wrote:
>>> if you hate misinformation, why not provide some correct information to
>>> counter it? i'd hazard a guess that nobody other than you in this thread
>>> knows what you mean by "deadly embrace".
>>>
>>> On 31 Oct 2010 05:47, "Bruce Ellis" <bruce.ellis@gmail.com> wrote:
>>>
>>> good call. i just hate misinformation. if there is any more misleading
>>> trash i will gladly give the offender Morgan's phone number.
>>>
>>> brucee
>>>
>>> On Sat, Oct 30, 2010 at 8:08 PM, Nemo <nemo.mbox@gmail.com> wrote:
>>>> let's call it rumba and go on....
>>
>>
>

Re: [9fans] A little more ado about async Tclunk

[Bruce Ellis]

That is correct.

On Sun, Oct 31, 2010 at 9:25 PM,  <fgergo@gmail.com> wrote:
> I believe livelock can happen.
>
> On 10/31/10, Bruce Ellis <bruce.ellis@gmail.com> wrote:
>> oh shut up. learn.
>>
>> you want Morgan's phone number?
>>
>> brucee
>>
>> On Sun, Oct 31, 2010 at 7:52 PM, roger peppe <rogpeppe@gmail.com> wrote:
>>> if you hate misinformation, why not provide some correct information to
>>> counter it? i'd hazard a guess that nobody other than you in this thread
>>> knows what you mean by "deadly embrace".
>>>
>>> On 31 Oct 2010 05:47, "Bruce Ellis" <bruce.ellis@gmail.com> wrote:
>>>
>>> good call. i just hate misinformation. if there is any more misleading
>>> trash i will gladly give the offender Morgan's phone number.
>>>
>>> brucee
>>>
>>> On Sat, Oct 30, 2010 at 8:08 PM, Nemo <nemo.mbox@gmail.com> wrote:
>>>> let's call it rumba and go on....
>>
>>
>
>

Re: [9fans] A little more ado about async Tclunk

[roger peppe]

[-- Attachment #1: Type: text/plain, Size: 284 bytes --]

an isbn number would be more useful.

On 31 Oct 2010 09:04, "Bruce Ellis" <bruce.ellis@gmail.com> wrote:

oh shut up. learn.

you want Morgan's phone number?

brucee


On Sun, Oct 31, 2010 at 7:52 PM, roger peppe <rogpeppe@gmail.com> wrote:
> if you hate misinformati...

[-- Attachment #2: Type: text/html, Size: 507 bytes --]

Re: [9fans] A little more ado about async Tclunk

[Gorka Guardiola]

After some research and reading I believe that deadly embrace was first used in:

E. W. Dijkstra "EWD108: Een algorithme ter voorkoming van de dodelijke
omarming" (in Dutch; "An algorithm for the prevention of the deadly
embrace" or so I 've been told.

as a synonym for deadlock or actually to describe a cycle in the WFG which is
the same. (the bankers algorithm is an algoritm to prevent deadlock).

Hoare cites Dijstra when he uses the term deadly embrace:
http://citeseerx.ist.psu.edu/viewdoc/download?doi=10.1.1.104.9460&rep=rep1&type=pdf
http://www.eecs.ucf.edu/~dcm/Teaching/COP4600-Fall2010/Literature/Semaphors-Djikstra.pdf

Hoare is talking about the events which happen when the process is in
an environment,
that is, what kind of inputs can make a process go forward. He is talking about
empty intersection of the possible events in the environment and the events of
the process. In Hoare's model, livelock and deadlock cannot be distinguished,
so deadly embrace in his terminology means both. This is because he is
establishing
an equivalence relation between all the processes which produce the same
interaction with the environment (a process is identified by trace).

So, yeah, deadlock is a synonym for deadly embrace. Yes, in Hoare's model
they are indistinguishable, so when he says deadly embrace, he can refer
to both.

Re: [9fans] A little more ado about async Tclunk

[Gorka Guardiola]

On Sun, Oct 31, 2010 at 2:06 PM, Gorka Guardiola <paurea@gmail.com> wrote:

> So, yeah, deadlock is a synonym for deadly embrace. Yes, in Hoare's model
> they are indistinguishable, so when he says deadly embrace, he can refer
> to both.
>

I mean livelock and deadlock are indistinguishable in Hoare's model.


--
- curiosity sKilled the cat

Re: [9fans] A little more ado about async Tclunk

[Gorka Guardiola]

On Sun, Oct 31, 2010 at 2:07 PM, Gorka Guardiola <paurea@gmail.com> wrote:
> On Sun, Oct 31, 2010 at 2:06 PM, Gorka Guardiola <paurea@gmail.com> wrote:
>
>> So, yeah, deadlock is a synonym for deadly embrace. Yes, in Hoare's model
>> they are indistinguishable, so when he says deadly embrace, he can refer
>> to both.
>>
>
> I mean livelock and deadlock are indistinguishable in Hoare's model.
>

On further thought, they are. I was thinking in terms of events with the
environment. But the events of gathering resources and backing up,
for example if the livelock comes from a deadlock avoiding algorithm,
can distinguish a livelock from a deadlock in Hoare's model too.
So the difference between a livelock and a deadlock is observable
and even in this case deadlock is equivalent to deadly embrace...

Re: [9fans] A little more ado about async Tclunk

[Richard Miller]

> In Hoare's model, livelock and deadlock cannot be distinguished,

This was true in the early days of CSP but the theory has evolved
a fair bit since then.  The current model explicitly includes
failures and divergences as part of the semantics of a process (in
addition to its traces); these were added in order to be able to
reason rigorously about deadlock and livelock respectively.

During my ten or so years at the PRG, I never once heard either Tony
Hoare or Carroll Morgan use the words "deadly embrace".

Re: [9fans] A little more ado about async Tclunk

[Eric Van Hensbergen]

http://www.olc.edu/~cdelong/jargon-4.4.7/jargon-4.4.7/html/D/deadly-embrace.html

In the case of 9P I believe the concern in context is waiting for
clunks when the server is dead means the waiter will never die.  Can
get particularly bad if its actually a communication failure with
bi-directional mounts where both sides can't exit because they can't
talk to each other.  Perhaps better explained here:

http://www.mail-archive.com/9fans@cse.psu.edu/msg03597.html

also discussed between brucee and russ here:

http://thedailyreviewer.com/compsys/view/9fans-clunk-clunk-10445370

The CSP/Hoare (University of Wollongong, really, is that a joke?)
reference that Brucee made is most likely here:
http://goo.gl/DphA

although it seems to point to:
Dijkstra, E.W. Cooperating sequential processes. in Programming
Languages	ed.	F.	Genuys.	- -
Academic ~.r.ess, New York, 1968 pp 43-112.
as the first reference to "deadly embrace".

While I have a bit of insight into what brucee is talking about, all
of these came from google "deadly embrace" and google "deadly embrace
clunk" for the Plan 9 specific references.  Its a always a bit of a
pain when brucee is a bit subtle, but its more of a pain when people
are to lazy to even bother searching.

(reading ahead in the thread, which I was too lazy to do before
searching, I see that Gorka at least bothered to search - he gets the
golden google prize - which I think might be an pickled egg from the
University of Woolongong)

     -eric


On Sun, Oct 31, 2010 at 3:52 AM, roger peppe <rogpeppe@gmail.com> wrote:
> if you hate misinformation, why not provide some correct information to
> counter it? i'd hazard a guess that nobody other than you in this thread
> knows what you mean by "deadly embrace".
>
> On 31 Oct 2010 05:47, "Bruce Ellis" <bruce.ellis@gmail.com> wrote:
>
> good call. i just hate misinformation. if there is any more misleading
> trash i will gladly give the offender Morgan's phone number.
>
> brucee
>
> On Sat, Oct 30, 2010 at 8:08 PM, Nemo <nemo.mbox@gmail.com> wrote:
>> let's call it rumba and go on....

Re: [9fans] A little more ado about async Tclunk

[Bruce Ellis]

There really is a University of Wollongong. The Wollong Group was a
Unix team in the 70s.

It a coal and steel port city about 50 miles south.

And the sprig of Wattle indeed goes to Gorka.

brucee

On Mon, Nov 1, 2010 at 1:21 AM, Eric Van Hensbergen <ericvh@gmail.com> wrote:
> http://www.olc.edu/~cdelong/jargon-4.4.7/jargon-4.4.7/html/D/deadly-embrace.html
>
> In the case of 9P I believe the concern in context is waiting for
> clunks when the server is dead means the waiter will never die.  Can
> get particularly bad if its actually a communication failure with
> bi-directional mounts where both sides can't exit because they can't
> talk to each other.  Perhaps better explained here:
>
> http://www.mail-archive.com/9fans@cse.psu.edu/msg03597.html
>
> also discussed between brucee and russ here:
>
> http://thedailyreviewer.com/compsys/view/9fans-clunk-clunk-10445370
>
> The CSP/Hoare (University of Wollongong, really, is that a joke?)
> reference that Brucee made is most likely here:
> http://goo.gl/DphA
>
> although it seems to point to:
> Dijkstra, E.W. Cooperating sequential processes. in Programming
> Languages       ed.     F.      Genuys. - -
> Academic ~.r.ess, New York, 1968 pp 43-112.
> as the first reference to "deadly embrace".
>
> While I have a bit of insight into what brucee is talking about, all
> of these came from google "deadly embrace" and google "deadly embrace
> clunk" for the Plan 9 specific references.  Its a always a bit of a
> pain when brucee is a bit subtle, but its more of a pain when people
> are to lazy to even bother searching.
>
> (reading ahead in the thread, which I was too lazy to do before
> searching, I see that Gorka at least bothered to search - he gets the
> golden google prize - which I think might be an pickled egg from the
> University of Woolongong)
>
>     -eric
>
>
> On Sun, Oct 31, 2010 at 3:52 AM, roger peppe <rogpeppe@gmail.com> wrote:
>> if you hate misinformation, why not provide some correct information to
>> counter it? i'd hazard a guess that nobody other than you in this thread
>> knows what you mean by "deadly embrace".
>>
>> On 31 Oct 2010 05:47, "Bruce Ellis" <bruce.ellis@gmail.com> wrote:
>>
>> good call. i just hate misinformation. if there is any more misleading
>> trash i will gladly give the offender Morgan's phone number.
>>
>> brucee
>>
>> On Sat, Oct 30, 2010 at 8:08 PM, Nemo <nemo.mbox@gmail.com> wrote:
>>> let's call it rumba and go on....
>
>

Re: [9fans] A little more ado about async Tclunk

[EBo]

> And the sprig of Wattle indeed goes to Gorka.

 Then who gets the daub?

   EBo --

Re: [9fans] A little more ado about async Tclunk

[Steve Simon]

> There really is a University of Wollongong. The Wollong Group was a
> Unix team in the 70s.

Though I am sure he is far to modest to say, our own Richard Miller
did some important work at the University of Wollongong:

http://www.usenix.org/publications/library/proceedings/usenix98/invited_talks/miller.ps

-Steve

Re: [9fans] A little more ado about async Tclunk

[Richard Miller]

> There really is a University of Wollongong. The Wollong Group was a
> Unix team in the 70s.

Just to clarify (or not), the Wollongong Group was a company in Palo
Alto (incorporated 6 June 1980 - not quite "70s" therefore) whose only
connection to the University of Wollongong was a software license - see
http://groups.google.co.uk/group/comp.os.plan9/msg/d73d2e1f276de7f1

Neither University nor Group is related to the University of Woolloomooloo
which is the setting for the Bruces' Philosophers sketch.

Apologies for raising this thread's signal/noise ratio.

Re: [9fans] A little more ado about async Tclunk

[Eric Van Hensbergen]

On Tue, Nov 2, 2010 at 8:49 AM, Richard Miller <9fans@hamnavoe.com> wrote:
>
> Apologies for raising this thread's signal/noise ratio.
>

Is that possible?  :)

   -eric

Re: [9fans] A little more ado about async Tclunk

[David Leimbach]

[-- Attachment #1: Type: text/plain, Size: 708 bytes --]

On Fri, Oct 29, 2010 at 10:26 AM, erik quanstrom <quanstro@quanstro.net>wrote:

> > Category Theory really doesn't say too much in general, but oddly enough
> it
> > applies nicely to computer science.  What's that mean? :-)
>
> that they're both abstract nonsense.
>
> - erik
>
>
Yeah... the most fun I had making something concrete was last weekend when I
wore to nasty blisters into my hands debarking about 170 feet of 18 inch
logs for a structure to camp under year round.  Computer software doesn't
often leave one with much to stand back and admire.  At least not so much
that non-software people can appreciate with you :-).

Sometimes it's nice to do things less abstract.

Dave

[-- Attachment #2: Type: text/html, Size: 1083 bytes --]

Re: [9fans] A little more ado about async Tclunk

[Charles Forsyth]

> Let's try to define 'decent' for this thread -- a decent fileserver is one
> on which close()s do not have any client-visible or semantic effect other
> than to invalidate the Fid that was passed to them. Lets see how many file
> servers we can think of that are 'decent': fossil, kfs, ken, memfs, ...

unfortunately, fossil and kfs both can have important visible state changes on a clunk,
so that lets them out.

Re: [9fans] A little more ado about async Tclunk

[erik quanstrom]

On Fri Oct 29 13:15:45 EDT 2010, forsyth@terzarima.net wrote:
> > Let's try to define 'decent' for this thread -- a decent fileserver is one
> > on which close()s do not have any client-visible or semantic effect other
> > than to invalidate the Fid that was passed to them. Lets see how many file
> > servers we can think of that are 'decent': fossil, kfs, ken, memfs, ...
>
> unfortunately, fossil and kfs both can have important visible state changes on a clunk,
> so that lets them out.

i think we're reducing this down to "it's easy to cache the hell
out of immutable files".

- erik

Re: [9fans] A little more ado about async Tclunk

[David Leimbach]

[-- Attachment #1: Type: text/plain, Size: 1143 bytes --]

On Fri, Oct 29, 2010 at 10:17 AM, erik quanstrom
<quanstro@labs.coraid.com>wrote:

> On Fri Oct 29 13:15:45 EDT 2010, forsyth@terzarima.net wrote:
> > > Let's try to define 'decent' for this thread -- a decent fileserver is
> one
> > > on which close()s do not have any client-visible or semantic effect
> other
> > > than to invalidate the Fid that was passed to them. Lets see how many
> file
> > > servers we can think of that are 'decent': fossil, kfs, ken, memfs, ...
> >
> > unfortunately, fossil and kfs both can have important visible state
> changes on a clunk,
> > so that lets them out.
>
> i think we're reducing this down to "it's easy to cache the hell
> out of immutable files".
>

Well that's like memoization of a pure function.  The answer is "yes",
because if the output of a function doesn't change when the same input is
applied, the function is just a table lookup anyway.  Same should hold true
for immutable files and the operations available on them not being able to
change the state.

When dependent state doesn't change, concurrency is easier to get right.

Dave


>
> - erik
>
>

[-- Attachment #2: Type: text/html, Size: 1793 bytes --]

Re: [9fans] A little more ado about async Tclunk

[Eric Van Hensbergen]

On Fri, Oct 29, 2010 at 12:18 PM, Charles Forsyth <forsyth@terzarima.net> wrote:
>> Let's try to define 'decent' for this thread -- a decent fileserver is one
>> on which close()s do not have any client-visible or semantic effect other
>> than to invalidate the Fid that was passed to them. Lets see how many file
>> servers we can think of that are 'decent': fossil, kfs, ken, memfs, ...
>
> unfortunately, fossil and kfs both can have important visible state changes on a clunk,
> so that lets them out.
>

qid.vers?  What else?  What % of apps depend on the visible stage
change?  Sorry - I'm not really trying to be an ass (even though I may
be succeeding), I'm just trying to get an idea of the actual negative
impact.  I imagine if I made this change in v9fs for Linux servers I
wouldn't see any negative behavior at all.

       -eric

Re: [9fans] A little more ado about async Tclunk

[Gorka Guardiola]

>> Let's try to define 'decent' for this thread -- a decent fileserver is one
>> on which close()s do not have any client-visible or semantic effect other
>> than to invalidate the Fid that was passed to them. Lets see how many file
>> servers we can think of that are 'decent': fossil, kfs, ken, 

Decent meant cacheable. Your meaning as nemo said... not so decent. cacheable != "clunk is nop"
even further
cacheable != "clunk can be processed asynchronously". Both concepts are orthogonal.

Cathegory theory is useful for thinking about topology and other things. It is not abstract nonsense, only abstract. It *is* noise in this thread though.

Re: [9fans] A little more ado about async Tclunk

[David Leimbach]

[-- Attachment #1: Type: text/plain, Size: 1246 bytes --]

On Fri, Oct 29, 2010 at 11:54 AM, Gorka Guardiola <paurea@gmail.com> wrote:

>
> >> Let's try to define 'decent' for this thread -- a decent fileserver is
> one
> >> on which close()s do not have any client-visible or semantic effect
> other
> >> than to invalidate the Fid that was passed to them. Lets see how many
> file
> >> servers we can think of that are 'decent': fossil, kfs, ken,
>
> Decent meant cacheable. Your meaning as nemo said... not so decent.
> cacheable != "clunk is nop"
> even further
> cacheable != "clunk can be processed asynchronously". Both concepts are
> orthogonal.
>

It might be more useful to think of it in terms of what it *does* mean.

Asynchronous clunkableness == no dependencies on ordering of clunk
processing to the next open call?

Cacheability can mean a lot of stuff depending on what is being cached, and
how such a cache becomes invalidated and refreshed.  I agree it's
orthogonal.


>
> Cathegory theory is useful for thinking about topology and other things. It
> is not abstract nonsense, only abstract. It *is* noise in this thread
> though.
>
>
>
It's tangentially related to an off to the side comment about cacheability.
 But yes it's definitely noise :-).

[-- Attachment #2: Type: text/html, Size: 1822 bytes --]

Re: [9fans] A little more ado about async Tclunk

[erik quanstrom]

> >> Let's try to define 'decent' for this thread -- a decent fileserver is one
> >> on which close()s do not have any client-visible or semantic effect other
> >> than to invalidate the Fid that was passed to them. Lets see how many file
> >> servers we can think of that are 'decent': fossil, kfs, ken,
>
> Decent meant cacheable. Your meaning as nemo said... not so decent. cacheable != "clunk is nop"
> even further
> cacheable != "clunk can be processed asynchronously". Both concepts are orthogonal.

that's sort of recursively begging the question.  cachable in what
sense?

> Cathegory theory is useful for thinking about topology and other things. It is not abstract nonsense, only abstract. It *is* noise in this thread though.

at the risk of the explaination devolving into general abstract nonsense, ...
in the english literature, category theory is often refered to as
abstract nonsense.  it's a mathematician joke, and a complement,
that i thought would be appreciated here.

http://en.wikipedia.org/wiki/Abstract_nonsense

- erik

Re: [9fans] A little more ado about async Tclunk

[Venkatesh Srinivas]

[-- Attachment #1: Type: text/plain, Size: 1207 bytes --]

On Fri, Oct 29, 2010 at 5:01 AM, Charles Forsyth <forsyth@terzarima.net>wrote:

> >What you are saying is that the problem could be something like:
>
> >-> Tclunk
> >(do not wait for response)
> >-> Topen (the file is exclusive)
>
> no, because what actually happens is closer to
>        A: Topen
>        ...
>        queue request to *another process* to send Tclunk
>        ...
>        A: Topen
>
> leading to either case 1
>        A: Topen
>        B: Tclunk
>        A: Topen
>
> or case 2
>        A: Topen
>        A: Topen
>        B: Tclunk
>
> depending on the scheduling of the two processes A and B
>
> introducing that other process introduces a new race, that simply did not
> exist before, because
> that other process didn't exist before. you always got case 1.
>
> and indeed, with the test i ran on the modified system usually it gets case
> 1
> because of timing, but eventually a case 2 shows up and the second open
> fails.
>
>
Correct. Either ordering is reasonable and not-a-problem when dealing with a
decent fileserver. There are certainly file servers and open options that
force single-open, but this approach is not for them.

-- vs

[-- Attachment #2: Type: text/html, Size: 1646 bytes --]

Re: [9fans] A little more ado about async Tclunk

[roger peppe]

On 28 October 2010 21:18, Charles Forsyth <forsyth@terzarima.net> wrote:
> the race is that there's nothing to say that the clunk completes before the
> process continues on to do something more, including some action that depends on the clunk completing,
> such as simply repeating the open. that open can fail if the mode or the name
> imposes particular constraints; constraints that depend on the order of events as
> expressed by the process.

in practise, there is no race if the tree is being imported via
plan9's exportfs(4)
because it services clunk requests synchronously.

on the other hand inferno's sys-export(2) services all requests
(except Tflush) asynchronously,
so the race will always be present.

when importing a file server directly, the presence of the race will naturally
depend on the file server's implementation.

so this trick is unsafe in general, but might be ok sometimes.

Re: [9fans] A little more ado about async Tclunk

[Lucio De Re]

On Fri, Oct 29, 2010 at 02:12:11PM +0100, roger peppe wrote:
>
> so this trick is unsafe in general, but might be ok sometimes.

So is the answer to add semantics to Topen or add a Treopen that obviates
the Tclunk?

++L

Re: [9fans] A little more ado about async Tclunk

[Charles Forsyth]

>in practise, there is no race if the tree is being imported via
>plan9's exportfs(4)
>because it services clunk requests synchronously.

there is indeed a race because another process is issuing the clunk(s),
not the one that's doing the open(s).

Re: [9fans] A little more ado about async Tclunk

[Charles Forsyth]

>on the other hand inferno's sys-export(2) services all requests
>(except Tflush) asynchronously,
>so the race will always be present.

no, that mistakes the problem. without the change, the issuing process
will see the clunk completed before it attempts any further operations:
no race. with the change, that is no longer true, even for a single (visible)
process.

Re: [9fans] A little more ado about async Tclunk

[David Leimbach]

[-- Attachment #1: Type: text/plain, Size: 409 bytes --]

On Wed, Oct 27, 2010 at 6:50 AM, Charles Forsyth <forsyth@terzarima.net>wrote:

> >Sorry that wing-commander can't package it for today.
>
> sorry old boy, it wasn't LMF: at first we thought it was a wizard wheeze,
> but one of the sprogs had a prang with the bally old semantics and the other
> brass hats ordered it back to the boffins
>
>
My droogs, this kind of talk adds a pain in my gulliver.

[-- Attachment #2: Type: text/html, Size: 688 bytes --]