On Dec 18, 2009, at 4:32 AM, Stephen Pair wrote:

> On Fri, Dec 18, 2009 at 4:01 AM, Josh Gargus <josh at schwa.ca> wrote:
> However, even if we were to use a single scheduler process, there is still some ambiguity about what should be the execution order of #future: messages.  For example:
> 
> (self future: 2000) foo.
> (self future: 1999) bar.
> 
> Which should execute first?  If a high-priority process interrupts, then the second line might not run for another 4ms.  Croquet ensures a deterministic order by not advancing the clock while executing queued messages in an island, and by making it illegal to send #future: messages from outside of the island (only #future messages are allowed).
> 
> 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"


They are.


> messages and that any #future: messages sent with the same delay should be queued in the order they are sent.


Without question.  This is a limitation of the current implementation.


>  Any message sent with a smaller delay should be queued before messages sent with a larger delay.  


That's my point above.  Should #bar be scheduled before #foo?  What about if there is a statement inserted between the two lines?  What if there are 10 statements?  What if one of the statements is waiting on a semaphore?

Within a Croquet island, it is guaranteed that clock-time would not advance while processing the statements, so it is guaranteed that #bar would be scheduled for execution before #foo.  If we're using "Time millisecondClockValue", then we have no such guarantee.


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


Agreed...


> (though, not necessarily all Processes should be made into such a "light VAT").  


Agreed...


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


And agreed!


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


Not currently.  Instead, you can use #waitTimeoutMSecs: to wait on a promise until it has resolved, or until the time-limit is exceeded.


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


+1  Mark's thesis is a great read.

Cheers,
Josh



> 
> 

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