[erlang-questions] how to build erlang system that accesses external resources
Tue Jul 21 16:32:08 CEST 2009
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):
2) Linked-in drivers
Fourth one is not in official distribution, so I will skip it (you can
read about it here ).
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  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 . 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 ). 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 .
(beware, it is very young and non-mature code)
2009/7/21 paweł kamiński <kamiseq@REDACTED>:
> 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.
> Paweł Kamiński
Every minute is to be grasped.
Time waits for nobody.
-- Inscription on a Zen Gong
More information about the erlang-questions