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
______________________
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