<div class="gmail_quote">On Fri, Dec 18, 2009 at 4:01 AM, Josh Gargus <span dir="ltr"><<a href="mailto:josh@schwa.ca">josh@schwa.ca</a>></span> wrote:<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">
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:<br>
<br>
(self future: 2000) foo.<br>
(self future: 1999) bar.<br>
<br>
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).<br>
</blockquote><div><br></div><div>Here are my thoughts on this.</div><div><br></div><div>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). 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).</div>
<div><br></div><div>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)?</div>
<div><br></div><div>- Stephen</div><div><br></div><div>P.S. I think Mark Miller's thesis is something everyone should read if they haven't already: <a href="http://www.erights.org/talks/thesis/">http://www.erights.org/talks/thesis/</a> ...I believe it is essential reading for anyone trying to think about how this stuff should work in squeak.</div>
</div><br><div><br></div>