I briefly read over the actor components of rubinius and it seems very
erlang-inspired: every actor spawns in its own thread with its own
mailbox. There are also some facilities to register actors for global
discovery. I do not believe there's yet any way to communicate between
The Io practice of actors via message passing does make more sense
with a language like fancy, particularly if over-the-wire
communication is handled transparently with the same primitives. I do
not know the cost of implementing that sort of communication if you
are using the many-threaded implementation of rubinius actors under
the sheets. There is talk of converting it to use fibers, but I do not
know how far that effort has gone. Depending on the architecture, that
may still be a costly library to build upon.
> Zusammenfassung für das heutige Thema
> Gruppe: http://groups.google.com/group/fancy-lang/topics
> Benachrichtigung für fancy...@googlegroups.com - 1 Nachricht in 1 Thema [2
> Thema: Benachrichtigung für fancy...@googlegroups.com - 1 Nachricht in 1
> Denny Abraham <em...@dennyabraham.com> Mar 04 08:38AM -0500 ^
> Sounds like a solid set of upcoming features. Will there be a
> functional difference between the Fancy actor library and the rubinius
> stdlib actors?
> Christopher Bertels <bakk...@googlemail.com> Mar 04 01:24PM -0800 ^
>> Sounds like a solid set of upcoming features. Will there be a
>> functional difference between the Fancy actor library and the rubinius
>> stdlib actors?
> It really depends on how their semantics are. I haven't really used them yet
> but that will change soon. If they fit my initial idea of how actors should
> work in Fancy, I'll just use them and add language-level support for them.
> Another approach to actors would be how they're done in Io, where every
> object can be an actor and have a mailbox for incoming asynchronous message
> sends. I'll look into that as well. What I like about that approach is that
> you don't have to create any special actor instances. Any object can be an
> actor at that point.
> It might make sense to use Rubinius' actor library underneath though to
> implement that approach to actors as well.