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

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

- 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.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.squeakfoundation.org/pipermail/squeak-dev/attachments/20091218/d0a35a62/attachment.htm