[chuck-users] can there be many ::ms in while?

[Kassen]

On 8/3/07, mike clemow <gelfmuse at 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.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.cs.princeton.edu/pipermail/chuck-users/attachments/20070803/c87ee35a/attachment.htm