[Eventmachine-talk] Erlang-like Processes

hemant
Mon, 27 Aug 2007 18:54:53 -0000

On 8/28/07, hemant <gethemant at gmail.com> wrote:
> On 8/28/07, Francis Cianfrocca <garbagecat10 at gmail.com> wrote:
> > All: I''ve added in the first implementation of Erlang-like
processes. It''s
> > in the current EM head revision. Unit tests are in
tests/test_spawn.rb.
> >
> > Thanks to James Edward Gray II for looking over the interface and
making me
> > realize that the first version really sucked. This one is very nice.
> >
> > Even if you''re not into Erlang, you might have noticed the
recent ruby-core
> > discussions about Fibers. These are basically non-scheduled threads
intended
> > to achieve lightweight concurrency. Your program is supposed to
schedule
> > them, and they run until your code tells them to yield.
> >
> > Erlang processes are a different approach to the same idea. A
"process" is
> > basically a data structure and a message queue. Your program can
"spawn"
> > (create) any number of processes (millions, if it wants to), and you
can
> > send "messages" to any process at any time. The messages
carry parameters
> > and cause the code in the process to execute to completion with the
given
> > parameters. Code that executes inside a process can send messages back
to
> > the same process or to other processes. Note that when you send a
message to
> > a process, the message does not execute immediately, but rather is
scheduled
> > for execution at some future time. The send-message call returns
> > immediately.
> >
> > EM now has essentially the same idea, except that "notify"
is used in place
> > of "send," which already has a different meaning in Ruby.
Here''s an
> > implementation of fibonacci with 25 processes:
>
> Francis,
>
> This is great.  * does little bow*.
>
>
> Ok so here are my doubts:
>
> 1. Are these processes real UNIX/Win32 processes or kinda lightweight
> Erlang processes (which are managed by Erlang VM). As i understand,
> probably second one is true. So can you tell some more about
> implementation? I mean, you are having some scheduler like ruby green
> thread scheduler which does this?
>
> 2. On my machine, with code from SVN, following code produces 1, whats
wrong?
>
> require "eventmachine"
>
> EM.run {
>   x = 1
>   y = 1
>
>   25.times {
>     s = EM.spawn do
>      x,y = y, x +y
>      # so if this is the body of spawned process, then i think its
> natural to think, notify should occur from here. Is my assumption
> flawed? Obviously, ''s'' is kinda erlang pid of process and
hence
> ''s.notify'' would also mean that, send a notification to
the spawned
> process. Also, i think, variable scope has to be preserved, and we
> should make sure that, spawned process doesn''t have access to
> variables, x and y. Again my assumptions could be flawed, since i
> don''t fully understand the implementation. but if we spawn 25
process
> and variables x and y are shared between them, then again we are
> creating predicament of threads, aren''t we?
>    end
>     s.notify
>   }
>
>   # In Erlang, normally there is a receive block in our code to
> indicate block thats going to receive external messages. here its not
> clear that, how "y" is getting populated in new process. In fact,
I
> have doubt that, "y" is available in spawned process, because
"y" was
> delcared globally in scope or "y" is available because "some
process
> passed a message to it".
>
>   rslt = EM.spawn {
>     puts "Fibonacci result: #{y}"
>     EM.stop
>   }
>   rslt.notify
> }
>
>
> >
> > You could also do the same thing with a single worker process, and
notify it
> > 25 times.
> >
> > This is actually a rather crummy sample because it assumes that the
> > notification of the rslt object will take place after the
notifications of
> > the fibonacci processes. On a uniprocessor, that assumption will be
valid.
> >
> > Next steps are: 1) to improve the performance; 2) add message
filtering like
> > Erlang has, which will allow you to just dump messages into a queue,
and one
> > or processes will respond to it based on parameters of the message;
and 3)
> > allow you to send messages to spawned processes that are actually
running in
> > other "real" processes, or on different machines.
> >
> > Comments? Suggestions?
>
> Again a big, thanks for this. Also, can you tell me, which files under
> source tree has implementation code, so i can look under the hood for
> better understanding.
>
> thanks.
>

Also, do you have plans to make them run on multiple CPUs and stuff?
Man, how you are gonna do this with Ruby 1.8? Will it be necessary to
have ruby1.9 for this?