On 02/09/15 19:23, Neeraj Sharma wrote:
The port doesn't support clustering (i.e. no epmd at present), which is
still in the works, wherein I have not made up my mind on the best way
possible to integrate it on rumprun. This port is running the Erlang VM
without the wrappers (which needless to say cannot be utilized as-is due to
fork/execv). There is a trivial echoserver as a sample application to
justify the effort :)
This is still bleeding edge, though I did try to test it as much on
qemu/kvm. This port should work on xen as well, though goes untested (since
I dont have a setup handy).
We've tried to make running software on Xen as much like KVM/qemu/bare
metal as possible, so I can't anticipate any difference in how the guest
software runs, and it should "just work".
Please note that it do not support SMP, because rumprun doesn't support it
at present though things might change (no commitment).
So apparently SMP is some sort of thing that Erlang prizes itself on --
news to me, but then again I hadn't used Erlang before today. I am sort
of against adding SMP support to Rumprun, for the reason that it will
make a lot of simple things insanely more complicated for what at least
to me is a minor use case. No, I'm not talking about locking. Locking
is trivial. Getting the cache interaction right is the hard thing.
For the cloud, I'd simply tell you to partition your work better, spin
up more guests, and avoid those atomic memory operations which make
everything slow and cache nightmares which make self-respecting
programmers cry themselves to sleep.
The problem with the above fairytale is the embedded/IoT target of
Rumprun, where one can't advocate running more instances because there's
no software layer below Rumprun for doing that. So, maybe we do need
some sort of SMP support. If someone does come up with patches, I'll at
least promise to meditate on them for a long time. Frankly, I drank the
message passing kool-aid a long time ago and believe that pushing SMP
into the application or driver part of the software stack is a 90's
architectural mistake. Of course, saying that you can only use x% of
your cores on a embedded system due to kool-aid flavour might not sell
that well ... Maybe there's some sort of pseudo-compromise somewhere
where Rumprun can act as an enabler for anarcho-syndicalist communes on
multiple cores.
ERLAPP_PATH=/apps/erlang
ERLHOME=/tmp
ERLPATH=/opt/erlang
rumprun qemu \
-I if,vioif,'-net tap,script=no,ifname=tap0' \
-W if,inet,static,10.0.120.101/24 \
-e ERL_INETRC=$ERLPATH/erl_inetrc \
-b images/erlang.iso,$ERLPATH \
-b examples/app.iso,$ERLAPP_PATH \
-i beam.hw.bin \
"-- -no_epmd -root $ERLPATH/lib/erlang -progname erl -- -home $ERLHOME
-noshell -pa $ERLAPP_PATH -s echoserver start"
In another terminal telnet to 10.0.120.101 and port 8080 to try it out.
Worked for me! (after a few silly mistakes of not managing to copypaste
the instructions properly. hint: when all else fails, use set -x)
