From mboxrd@z Thu Jan 1 00:00:00 1970 MIME-Version: 1.0 In-Reply-To: <9235d3fce85ed5cfde0d027fc453f734@coraid.com> References: <9235d3fce85ed5cfde0d027fc453f734@coraid.com> Date: Fri, 29 Oct 2010 10:25:26 -0700 Message-ID: From: David Leimbach To: Fans of the OS Plan 9 from Bell Labs <9fans@9fans.net> Content-Type: multipart/alternative; boundary=00504502c8bca0ca050493c4bea5 Subject: Re: [9fans] A little more ado about async Tclunk Topicbox-Message-UUID: 7278f9fa-ead6-11e9-9d60-3106f5b1d025 --00504502c8bca0ca050493c4bea5 Content-Type: text/plain; charset=ISO-8859-1 On Fri, Oct 29, 2010 at 10:17 AM, erik quanstrom 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 > > --00504502c8bca0ca050493c4bea5 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable

On Fri, Oct 29, 2010 at 10:17 AM, erik q= uanstrom <= 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 dec= ent fileserver is one
> > on which close()s do not have any client-visible or semantic effe= ct 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, k= en, memfs, ...
>
> unfortunately, fossil and kfs both can have important visible state ch= anges 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. =A0The answer is "yes"= ;, because if the output of a function doesn't change when the same inp= ut is applied, the function is just a table lookup anyway. =A0Same should h= old 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
=A0

- erik


--00504502c8bca0ca050493c4bea5--