[squeak-dev] Re: Future examples (Re: Inbox: #future keyword for asynchronous message invocation)

Stephen Pair stephen at pairhome.net
Fri Dec 18 13:42:27 UTC 2009

On Fri, Dec 18, 2009 at 7:51 AM, Andreas Raab <andreas.raab at gmx.de> wrote:
>  So, what about deadlines?  Is there a way to set a deadline for a future
>> send to be executed (after which your promise would yield some kind of
>> timeout exception)?  And, related to that, what about some provisions for
>> rejecting messages (i.e. if a message queue has reached some maximum
>> capacity or it is falling behing?  How does Croquet handle such things
>> (especially when it would have to be handled is such a way that guarantees
>> identical results across replicated islands running on hardware with
>> potentially very different characteristics)?
> Croquet handles these issues as failures on the transport level, i.e., just
> like loosing the network connection. Also, for timeouts keep in mind the
> comment above (no timed inter-island futures) and that otherwise all Croquet
> time is simulation time anyway, that is the advance of time is determined by
> the flow of messages from the router. As a consequence, 'timeouts' that
> happen in island time are always replicated since it only depends on the
> sequence of messages. In practice we use this for example for detecting lack
> of presence indications from participants in Teleplace (you get a red
> exclamation mark next to the user if we've timed out the replicated
> heartbeat from that participant).

Ok, I'm not sure I get all this...if there were three participants in a
replicated island, are you saying that if for some reason a message cannot
be delivered successfully to one participate (and I'm thinking specifically
of the case where that participant is overloaded), that effectively that
replica goes into some disconnected state?  Presumably it would later
re-sync state with one or more of the other islands once it recovers.
 However, I thought Croquet had some kind of a graceful degradation that
wouldn't result in a less powerful machine being ejected outright.  (btw,
sorry that I'm asking these questions and haven't studied Croquet more
closely, I've read the papers and played around with it a little, but
haven't dug into the code much)

So...thinking about how Croquet might allow more graceful degradation: does
Croquet enforce these strict requirements around successful queuing of
messages to all replicas, but the replicated state effectively consists of
just the model of the world and not any (or not a lot) of the objects
involved in rendering the world?  And, since most of the computational load
would be in rendering, Croquet would, in fact, allow for a lot of
degradation of the rendering and a participant would not get disconnected
just because the rendering can't keep up with 30 fps?  As long as the
replicated island (consisting of just an abstract model of the world and not
requiring a lot of computational load) is able to keep up with the message
flow, the participant would remain connected?

Also, how does Croquet deal with really large worlds?  Do you subdivide a
large world into hectares or something (or the 3D equivalent of
hectares...is there a word for that?) and do you just replicate the hectare
the avatar currently resides in and the immediately adjacent hectares...and
make the hectares sufficiently large that you would always have enough to
render sufficiently far into the distance?  What about objects that might
sit on the boundary of multiple hectares?

- Stephen
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.squeakfoundation.org/pipermail/squeak-dev/attachments/20091218/0cf1ddad/attachment.htm

More information about the Squeak-dev mailing list