linked-in drivers once again

[Karel Van Oudheusden]

Hello once again,

I have a few specific questions and a few general questions regarding
linked-in drivers. Since I am new to Erlang and C programming, I am
having the time of my life.

I have written an erlang file 'erlToeasiest.erl' that communicates with
the C file 'easiest_drv.so'.  (see attachment for the details).  The C
file 'easiest_drv.c' correctly compiles (and has kindly been checked by
Vance Shiley). I therefore mainly have questions about the
'erlToeasiest.erl' file.

Regarding the 'erlToeasiest.erl' file:

- I use the following statement:
Port = open_port({spawn, "./easiest_drv.so"}, [])
instead of using the statement:
Port = open_port({spawn, "easiest_drv"},[])
The first statement works, the latter does not. Yet I am confused
because all the examples I have seen follow the second convention.

- Then there's the issue of the empty list in the above statements. I
assume I can for instance use [{packet, 2}] for communication between my
Erlang process and the driver.  What does the empty list actually imply?

- How does the communication between the Erlang process and the driver
work precisely?  If I were to use a binary for communication, I
understand that a reference to the binary is passed. So this is in a
sense shared memory communication?
And what exactly is a binary? Do they use this principle in for instance
Java-C communication or is this unique for Erlang and if so, what is the
drawback?

- According to the "byteorder" driver code the following works (but I
don't know why):
Port ! {self(), {command, "test"}},
receive
    {Port, {data, [$l|_]}}  -> ...
    {Port, {data, [$m|_]}}-> ...
    {Port, closed}  -> ...
...
Where do the $l and $m come from?
Besides, my code contains the above but does not work. I have debugged
it and it appears that the driver is closed. ...
-----------------------------------------
And now more general questions:

- I am building a distributed (multi-tasking) application written mainly
in Erlang. However, the application contains a lot of large
lookup-tables that are consulted very often. These lookup-tables can
efficiently be implemented in different ways in an imperative (e.g. C
language) approach. Therefore, I want to use Erlang for the
multi-tasking, fault-tolerance, and control intelligence of the
language. On the other hand, I want to use C or C++ for the total memory
management of the lookup tables.

The intention is to use a linked-in driver for the C part. Is this
approach reasonable? The C code will be passive code but maybe (probably
not) in the future I will want to make it multi-tasking (posix threads
...) as well.

I know there are possibilities with the Mnesia data base but I have not
looked at that yet and for the moment I am not planning to either. I
really want to use these two different approaches (functional and
imperative) together in one application. And if I am not mistaken, this
was/is one of the main advantages of the Erlang philosophy (yet I am
having some trouble finding the documentation for this).

The Erlang process will consult the C driver often. Yet I am not
planning to use a binary for this since only a small message is sent
between the two: the Erlang process sends a key to the C data structure.
The C driver sends a value (corresponding to the key) back to the Erlang
process.

I am also assuming that in the long run I might even be able to specify
which data structures are placed where exactly in physical memory.
However, this is a C compiler problem so this shouldn't be a problem
regarding Erlang or is it?

Note that I am also assuming that the application I am talking about is
mainly a data-dominated problem. Therefore I consider Erlang
inappropriate for the data management (of the lookup tables). I am
however wandering whether at the end of the day the concurrency in
Erlang will be the most critical factor (in terms of performance) or
will it (still) be the data management (e.g. retrieving different memory
often) assuming that I am using the above stated approach?

And last but not least, if anybody has an application like the one I am
talking about in which a lot of C code interacts with Erlang code I
would be happy to check it out.


thanks a lot for your comments,
KVO.

-------------- next part --------------
An embedded message was scrubbed...
From: Van Oudheusden <voudheus@REDACTED>
Subject: (no subject)
Date: Wed, 27 Jun 2001 22:13:50 +0200
Size: 9946
URL: <http://erlang.org/pipermail/erlang-questions/attachments/20010627/e0ee966e/attachment.eml>