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

[David Leimbach <leimy2k@gmail.com>]

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