Re: [fancy-lang] Benachrichtigung für fancy-lang@googlegroups.com - 2 Nachrichten in 1 Thema

[Denny Abraham]

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
VM's.

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.

:Denny

2011/3/5 <fancy-lan...@googlegroups.com>:
>   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
> Aktualisierungen]
>
>  Thema: Benachrichtigung für fancy...@googlegroups.com - 1 Nachricht in 1
> Thema
>
> 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?
>
> :Denny
>
>
>
>
> Christopher Bertels <bakk...@googlemail.com> Mar 04 01:24PM -0800 ^
>
> Hi,
>
>
>> 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.
>
> Christopher.
>
>

[Christopher Bertels]

Hi,

Yeah for per-object actors it makes more sense to have them be based on coroutines (Fibers). Erlang's processes are light-weight processes, too, although not cooperative in nature.

But for programs with lots of actors and asynchronous message passing you don't want to spawn a kernel thread for each of them.

I will look into implementing it soon, if you're interested in helping out, come by in #fancy to discuss things.