linked-in drivers once again

[Vance Shipley]

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

I only checked it as far as getting your init function working so that
the driver would load with erl_ddll.

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

Why the former works is a fluke.  The latter doesn't work because you
have not initialized erlang_port to -1.  You are checking to see if
it is -1 and if not returning -1 to abort:

	if (erlang_port != (ErlDrvPort) -1)
		return((ErlDrvData) -1);

> Since I am new to Erlang and C programming ...

The reason that the fisrt example works is one of the tricky things
about debugging C programs.  Sometimes things that shouldn't work do.
When you ran this program with that calling syntax erlang_port just 
happened to end up as -1.  Since you hadn't initia;ized it it could be
anything, no guarantees.  Often with uninitialized variables/pointers
things will work and then later when you make a perfectly valid code
change they stop working.  You rack your brain staring at the new code
thinking it must be bad but it isn't.  You just moved things around and
now your variable/pointer has a value that doesn't work for you.

This is one of the reasons we code in Erlang!  :)

	-Vance

Vance Shipley
Motivity Telecom Inc., Telephony Signaling Software
+1 519 579 5816
vances@REDACTED

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