From mboxrd@z Thu Jan  1 00:00:00 1970
To: 9fans@cse.psu.edu
Subject: Re: [9fans] vfork and paging
From: rog@vitanuova.com
MIME-Version: 1.0
Content-Type: text/plain; charset="US-ASCII"
Content-Transfer-Encoding: 7bit
Message-Id: <20011002183911.5DBE8199ED@mail.cse.psu.edu>
Date: Tue,  2 Oct 2001 19:51:15 +0100
Topicbox-Message-UUID: fb11a8dc-eac9-11e9-9e20-41e7f4b1d025

> I think the way acme (and later rio) manages the resources for the client
> connections - the Xfid data type and control described in the acme paper
> - is one of the best ideas I ever had.  Dynamic channels roll!

the difficult part is flushing, of course.

i've had happy experiences using procs and channels for managing
animations in a card game program where any number of cards can be
flying around the place concurrently in response to network events,
the user continues to interact at the same time, and the internal
database must be kept consistent.

it uses processes in a way that in other systems would be considered
profligate (one process for each animation plus one for each
destination) but performance is just fine, even on slower processors
(e.g.  on the ipaq).

and whereas such a system built in a conventional style would probably
be highly fragile and involve some quite difficult state transitions,
this is robust and it would be trivial to add some more interesting
kinds of animations (e.g.  dice rolling) without impacting the
complexity of any of the rest of the system.

in fact, i *tried* to implement such a system on another system
(NeXTstep) and failed; too much complexity all at once.

  rog.