On 8/3/07, mike clemow <gelfmuse@gmail.com> wrote:

Okay, I'm having a bit of an "ah-ha!" moment here.

Great! I'm having coffee here :Ź).

  It makes sense to
me when described like this.  If I understand this process correctly,
data-sharing aside, this is functionally equivalent to using the
"chuck --loop" invocation to start the VM and sporking shreds with
"chuck + this.ck" and "chuck + that.ck."  Or is that more like
Machine.add()?

Actually, Machine.add() and "chuck +" are basically equivalent (aside from returning a Id in the .add() case). Sporking also results in new code being run in a new shred but it's different in that it shares the name-space of the parent. Also; if a shred sporks a new shred and then "dies" all it's sporked childeren will be "killed" too, shreds it has added using Machine.add() won't die in that case.

According the manual, sporking a shred will return a reference to the
shred, while using Machine.add() will return the ID. Can one pass
messages between shreds in the VM like in Erlang processes using this
information? Using a shared variables to store state information
might get kind of hairy in big programs.

Yes, you definately could. You could, for example use events, extended to have a id as a parameter and have sporked shreds listen for that event, then compare that "id parameter" to it's own.

I sugest you read the manual section on events, events are cool; quite simple, very powerfull and they can be extended.

If that's not enough you might need to look into classes. Classes can also spork their own shreds upon construction and in that case you can use the class instance's name.

I hope that answers your question, if you are after something more specific we can look into that as well.

Happy to have been able to contribute to your "Ah-ha!",
Kas.