Stephen Pair wrote:
> Here are my thoughts on this.
> 
> I think the important thing here is to clearly define the semantics 
> before lots of code gets written that uses this...so, I would say that 
> #future messages should be the equivalent of "future: 0" messages and 
> that any #future: messages sent with the same delay should be queued in 
> the order they are sent.  Any message sent with a smaller delay should 
> be queued before messages sent with a larger delay.  These semantics 
> would apply for messages sent from within the same process (which is 
> what I believe we consider the unit in squeak that maps to Miller's 
> VAT).  Messages being queued from different originating processes would 
> have no guaranteed ordering (but, if we were to introduce Croquet style 
> replication of processes (within or between squeak images), once an 
> ordering is established, it would be maintained for all replicas...also 
> I think that would necessitate introducing a psuedo-time like TeaTime).

All of the above is exactly as intended. I'll expand on one issue: The 
argument-less #future is logically considered a message sent "ASAP", 
i.e., in the next available time slot. This has little meaning for 
in-process communication and is exactly equivalent to "self future: 0" 
but in a remote messaging environment (like Croquet) the distinction 
becomes meaningful because the message takes a round trip for obtaining 
the time stamp and consequently "ASAP" is never equal to zero in 
real-time. Because of this property we defined early on that timed 
futures between islands are ill-defined (depending on round-trip latency 
they may never arrive "in time") and don't allow them.

> As I mentioned, I think a squeak Process should be the unit where these 
> queues are maintained and be the squeak equivalent of a VAT (though, not 
> necessarily all Processes should be made into such a "light VAT").  And, 
> large subsystems (like a Morphic project) where things should logically 
> be contained within a single VAT should be refactored as necessary and 
> over time to fit in that model (i.e. anything running outside the 
> Morphic project's VAT should updated to communicate with morphic using 
> only future sends).  Of course, these "light-VATs" won't do anything to 
> help with the shared state concurrency issues that can (and will) 
> arise...the burden of dealing with that will have to be on the person 
> writing the code (for now).

Agree on all of these points.

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

> P.S. I think Mark Miller's thesis is something everyone should read if 
> they haven't already: http://www.erights.org/talks/thesis/ ...I believe 
> it is essential reading for anyone trying to think about how this stuff 
> should work in squeak.

Yes, definitely. Mark has been greatly influential on all of this.

Cheers,
   - Andreas