[erlang-questions] how to build erlang system that accesses external resources

3 views
Skip to first unread message

paweł kamiński

unread,
Jul 21, 2009, 10:06:58 AM7/21/09
to Erlang
hi all,
I have a working system written in delphi (and Im not a delphi expert and it
wasnt my idea :)) that creates few threads (like 10-20) and each thread is
able to load some dll and then through that dll is performing some action on
local db or on other resource. the problem is that it is very hard now to
controll threads, force them to kill etc and as I can see operating system
is not helping at all so it is a p.i.t.a. so I was thinking to port the
system into erlang. but we produced a lot of those dlls so it will be almost
impossible to rewrite them into erlang once again.

So (as Im quite new to erlang) I imagine that I create a erlang's system
that starts and manages processes with ease but then I somehow need to load
dll by some external system proccess and talk with it through ports. so it
seems to me Im back where I started, doesnt it? again I cant have only one
proccess for all dll loaded on the OS side, and I really cant figure out how
I should plan everything.

I havent read much about ports so maybe I should go through the chapter
again, if so just tell me it is a good direction here.

pozdrawiam
Paweł Kamiński

kam...@gmail.com
pkamin...@gmail.com
______________________

Gleb Peregud

unread,
Jul 21, 2009, 10:32:08 AM7/21/09
to paweł kamiński, Erlang
All options are described here http://erlang.org/doc/tutorial/part_frame.html

Basically there are 3 (or four if FFI is counted) options (please
correct me if I'm wrong):
1) Ports
2) Linked-in drivers
3) C-nodes
4) FFI

Fourth one is not in official distribution, so I will skip it (you can
read about it here [1]).

Third one is quite complex to be written from scratch, but doable. I
haven't written any C node in Delphi or C, so other would provide more
information. Though writing Python C-nodes with twotp [3] is very easy
:)

Second one is strongly discouraged. It would mean that your Delphi/C
code would be running inside Erlang VM and any single bug can bring
done whole VM [2]. Moreover writing linked-in drivers is cumbersome
and you have to obey few rules (e.g. timing), not to mention pain of
managing threads inside the linked-in driver... Though if you need a
fast and long-term solution you could use it, but cost of development
would be much higher than using ports.

If it is imperative to use Erlang I would go with ports. Ports are
just simple external processes (it could C program, Delphi or even
bash script), which communicates with Erlang using stdio/stdout. You
have to define a communication protocol (it could be simple line text
based protocol or some more complex binary protocol). Or you could use
erl_interface / ei libraries to manage erlang term coding/decoding. It
is really easy to manage ports from within Erlang (text line based
example here [4]). This way you would be able to start multiple
external processes, which will do the job (using existing DLLs) and
you would communicate with them through stdio/stdout.

When ports are used and everything's written according to OTP
principles managing it is a breeze [5].

1: http://muvara.org/crs4/erlang/ffi/
2: http://erlang.org/doc/tutorial/c_portdriver.html
3: https://launchpad.net/twotp
4: http://github.com/gleber/sha1cruncher/blob/d2e8f0b924ed5d16ade815d9a1fd90cd129ebc40/src/main.erl#L160
(beware, it is very young and non-mature code)
5: http://www.trapexit.org/Writing_an_Erlang_Port_using_OTP_Principles

2009/7/21 paweł kamiński <kam...@gmail.com>:

--
Gleb Peregud
http://gleber.pl/

Every minute is to be grasped.
Time waits for nobody.
-- Inscription on a Zen Gong

________________________________________________________________
erlang-questions mailing list. See http://www.erlang.org/faq.html
erlang-questions (at) erlang.org

paweł kamiński

unread,
Jul 21, 2009, 10:40:26 AM7/21/09
to Gleb Peregud, Erlang
ok so for example I start proccess in erlang that creates port for me and
all I need to do is to write a code that will handle dll. then I pass dll
name to the port and the OS thread is transparent to me. ok I will read
again about this. thanks
Reply all
Reply to author
Forward
0 new messages