Messaging models: Tweak vs. Croquet

I've been studying the Message model of Tweak for the past few
days, and I've gotta say, It seems pretty complicated. Here is
how it works, as far as I have been able to tell:

Asynchronous messages are handled by a package called
"Scripting", and are called scripts in tweak, likely as a
hangover from eToys. So I'll call them Scripts

Tweak has first-class events that are partially built into the
language as language extensions for common cases. Events are the
most common way that a script gets started. One can also start a
script manually, by doing "self startScript: [ ]"

A Script is an instance of ScriptProcess, a subclass of Process.
All scripts are managed by an instance of ScriptScheduler. The
ScriptScheduler makes sure that only one Script is ever
executing at a time. When a script stops or pauses, the
scheduler starts another script, and runs it until it pauses or
completes. Scripts are non-preemitive, so memory contention is
non-existent.

As far as I can tell, the system is designed so that there is
only one ScriptScheduler per island, although nowhere is this
enforced, since Islands do not know about the scripts and
schedulers running on them.

One aspect of the system that greatly confused me was debugging.
Tweak has a very cool debugger that is quite hidden; you can
cause it to trigger when a certain event gets sent to a certain
object, by using the "Debug" menu item of the red halo. It
intercepts all scripts that the script under debugging tries to
start, and pauses them, only allowing them to be resumed under
user control. It does this via a built-in mechanism of
ScriptProcess (the class that scripts are an instance of); if a
script has tracing enabled, it sends events (scripts) to
interested parties when it creates a script.

The part that confused me is what happens to the scripts that
the debugger manually stops. Is a new ScriptScheduler created to
handle them?


This is quite different from the Croquet model, which is more
similar to the E model, which I have blogged about:
http://mtfulmer.wordpress.com/2008/03/21/e-concurency-model/

I haven't studied the croquet model in detail, but it has several
differences:

There are no events, as far as I can tell, and Scripts are not
created manually.

Instead, asynchronous messaging is done by sending a future
message to an object. Like in E, future messages can be sent to
either local or remote (in another island) objects.

Croquet islands (which are instances of TIsland rather than
Island, as in Tweak), explicitly manage all future messages,
rather than delegate to an unknown ScriptScheduler.

Unlike tweak Scripts, future messages cannot pause; they must
run to completion. This is the same as with E.


Finally, the novel feature of Croquet (I should be saying
TeaTime; oh well), is that all future messages are timestamped,
and are only run after a certain time on the Island clock has
occurred. The timestamp can be set either explicitly (to insert a
deliberate time delay), or can be implicit, in which the message
will be executed as soon as all it's dependencies have been
resolved, which may have been in the past.


Now, open questions I have:

Does Tweak allow delayed messages as in croquet, or does it use
delay waiting inside the scripts instead?

Croquet, as an explicit design decision, does not allow a
message to be stopped once it has started; if something needs to
be done later, it must be a new message, not a continuation of
an old one. Why is this?

Some tweak scripts can be stopped and run in the debugger, while
others continue executing. Is this possible in Croquet? I'm not
sure, due to Croquet being explicit about time. Tweak scripts,
from what I can tell, are supposed to be order-independent.

Is ScriptScheduler really necessary? It seems like it and the
TIsland message queue serve the same purpose.

And finally, how well do I understand all of this?

--
Matthew Fulmer -- http://mtfulmer.wordpress.com/

On Jun 20, 2008, at 5:24 PM, Matthew Fulmer wrote:

> I've been studying the Message model of Tweak for the past few
> days, and I've gotta say, It seems pretty complicated.

I've heard Andreas say that while he likes the way asynchronous  
scripts work from the end-user's (i.e. of something like eToys) point  
of view, they're a lousy way to engineer a system because the result  
is difficult to debug and maintain.  I've also heard him say that if  
he were to rewrite Tweak, he'd do it using a Croquet-like event loop.

<snip discussion about how it actually works>

Croquet uses Tweak's scripting mechanism to signal events inside the  
island and observe them outside.

> Instead, asynchronous messaging is done by sending a future
> message to an object. Like in E, future messages can be sent to
> either local or remote (in another island) objects.
>

Both Tweak and Croquet have an explicit notion of time (can send a  
message that will be executed after some specified interval); I don't  
believe that E has this.

Nope, "simplified TeaTime" :-)

> is that all future messages are timestamped,
> and are only run after a certain time on the Island clock has
> occurred. The timestamp can be set either explicitly (to insert a
> deliberate time delay), or can be implicit, in which the message
> will be executed as soon as all it's dependencies have been
> resolved, which may have been in the past.

The second part isn't quite right.  I'm assuming that we're talking  
about messages sent within an island (since future messages with an  
explicit delay can't be sent from outside, via a far-ref).  There is  
no explicit tracking of dependencies.  When you send a #future message  
without an explicit delay, it is inserted into the island's queue in  
the appropriate place (as determined by the island's current time and  
sequence number), and is executed when it reaches the front of the  
queue.

BTW, speaking of the sequence number... while looking over the code to  
make sure I'm not talking nonsense, I think I figured out the FIXME in  
#scheduleMessage:at: .  Hopefully it will still make sense tomorrow  
morning :-)

>
> Now, open questions I have:
>
> Does Tweak allow delayed messages as in croquet, or does it use
> delay waiting inside the scripts instead?

I'm not a Tweak expert, so I'll pass on this one.

> Croquet, as an explicit design decision, does not allow a
> message to be stopped once it has started; if something needs to
> be done later, it must be a new message, not a continuation of
> an old one. Why is this?
>

(Funny, Andreas and I happened to talk about this today... I was  
confirming my understanding that Eliot's addition of closures as part  
of his Cog VM work did not change this fundamental constraint of  
Croquet's current implementation)

I'm assuming that you're talking about continuations as used in  
Seaside.  The short answer is because each Croquet island runs in a  
single process; if you suspend that Process, no progress is made.  A  
longer answer would delve into the difficulties of serializing  
processes/context and reviving them in a new image, the question of  
how the Scheduler wakes up the continuation while maintaining  
deterministic replication (Croquet currently avoids such interactions  
with the scheduler), etc.

Andreas has had a lot of experience with this, dating back to the  
Disney days; he understands all of the gotchas far better than I do.  
Suffice to say that it's a hassle.  He also notes that some aspects of  
this might be easier in a system that avoids ubiquitous access to  
global state, such as Newspeak or E.

> Some tweak scripts can be stopped and run in the debugger, while
> others continue executing. Is this possible in Croquet?

Not within a single island.  However, it is possible to create Croquet  
applications with finer granularity than one-island-per-3d-space  
(although to my knowledge, nobody has created such applications).

> I'm not
> sure, due to Croquet being explicit about time. Tweak scripts,
> from what I can tell, are supposed to be order-independent.

No, Tweak relies on specific invariants of the scheduler (don't ask me  
what they are, ask Andreas) to provide deterministic script execution  
order.

>
> Is ScriptScheduler really necessary? It seems like it and the
> TIsland message queue serve the same purpose.
>
> And finally, how well do I understand all of this?

Pretty well, it seems to me.

Josh

>
>
> --
> Matthew Fulmer -- http://mtfulmer.wordpress.com/

Why might my TIsland (created using a TLocalController) be receiving
errors: "Past message encountered:  (various)" ?