In order to use any of the Erl_Interface functions, include the following lines in your code:

Determine where the top directory of your OTP installation is. You can find this out by starting Erlang and entering the following command at the Eshell prompt:

To compile your code, make sure that your C compiler knows where to find erl_interface.h by specifying an appropriate -I argument on the command line, or by adding it to the CFLAGS definition in your Makefile. The correct value for this path is $OTPROOT/lib/erl_interfaceVsn/include, where $OTPROOT is the path reported by code:root_dir/0 in the above example, and Vsn is the version of the Erl_interface application, for example erl_interface-3.2.3

When linking, you will need to specify the path to liberl_interface.a and libei.a with -L$OTPROOT/lib/erl_interface-3.2.3/lib, and you will need to specify the name of the libraries with -lerl_interface -lei. You can do this on the command line or by adding the flags to the LDFLAGS definition in your Makefile.

Also, on some systems it may be necessary to link with some additional libraries (e.g. libnsl.a and libsocket.a on Solaris, or wsock32.lib on Windows) in order to use the communication facilities of Erl_Interface.

If you are using Erl_Interface functions in a threaded application based on POSIX threads or Solaris threads, then Erl_Interface needs access to some of the synchronization facilities in your threads package, and you will need to specify additional compiler flags in order to indicate which of the packages you are using. Define _REENTRANT and either STHREADS or PTHREADS. The default is to use POSIX threads if _REENTRANT is specified.

Note that both single threaded and default versions of the Erl_interface and Ei libraries are provided. (The single threaded versions are named liberl_interface_st and libei_st). Whether the default versions of the libraries have support for threads or not is determined by if the platform in question has support for POSIX or Solaris threads. To check this, have a look in the eidefs.mk file in the erl_interface src directory.

Before calling any of the other Erl_Interface functions, you must call erl_init() exactly once to initialize the library. erl_init() takes two arguments, however the arguments are no longer used by Erl_Interface, and should therefore be specified as erl_init(NULL,0).

Data sent between distributed Erlang nodes is encoded in the Erlang external format. Consequently, you have to encode and decode Erlang terms into byte streams if you want to use the distribution protocol to communicate between a C program and Erlang.

The Erl_Interface library supports this activity. It has a number of C functions which create and manipulate Erlang data structures. The library also contains an encode and a decode function. The example below shows how to create and encode an Erlang tuple {tobbe,3928}:

Alternatively, you can use erl_send() and erl_receive_msg, which handle the encoding and decoding of messages transparently.

Refer to the Reference Manual for a complete description of the following modules:

The previous example can be simplified by using erl_format() to create an Erlang term.

Refer to the Reference Manual, the erl_format module, for a full description of the different format directives. The following example is more complex:

As in previous examples, it is your responsibility to free the memory allocated for Erlang terms. In this example, erl_free_compound() ensures that the complete term pointed to by ep is released. This is necessary, because the pointer from the second call to erl_format() is lost.

The following example shows a slightly different solution:

In this case, you free the two terms independently. The order in which you free the terms ep and ep2 is not important, because the Erl_Interface library uses reference counting to determine when it is safe to actually remove objects.

If you are not sure whether you have freed the terms properly, you can use the following function to see the status of the fixed term allocator:

Refer to the Reference Manual, the erl_malloc module for more information.

An Erlang pattern is a term that may contain unbound variables or "do not care" symbols. Such a pattern can be matched against a term and, if the match is successful, any unbound variables in the pattern will be bound as a side effect. The content of a bound variable can then be retrieved.

erl_match() is used to perform pattern matching. It takes a pattern and a term and tries to match them. As a side effect any unbound variables in the pattern will be bound. In the following example, we create a pattern with a variable Age which appears at two positions in the tuple. The pattern match is performed as follows:

Refer to the Reference Manual, the erl_match() function for more information.

In order to connect to a distributed Erlang node you need to first initialize the connection routine with erl_connect_init(), which stores information such as the host name, node name, and IP address for later use:

Refer to the Reference Manual, the erl_connect module for more information.

After initialization, you set up the connection to the Erlang node. Use erl_connect() to specify the Erlang node you want to connect to. The following example sets up the connection and should result in a valid socket file descriptor:

erl_err_quit() prints the specified string and terminates the program. Refer to the Reference Manual, the erl_error() function for more information.

Epmd is the Erlang Port Mapper Daemon. Distributed Erlang nodes register with epmd on the localhost to indicate to other nodes that they exist and can accept connections. Epmd maintains a register of node and port number information, and when a node wishes to connect to another node, it first contacts epmd in order to find out the correct port number to connect to.

When you use erl_connect() to connect to an Erlang node, a connection is first made to epmd and, if the node is known, a connection is then made to the Erlang node.

C nodes can also register themselves with epmd if they want other nodes in the system to be able to find and connect to them.

Before registering with epmd, you need to first create a listen socket and bind it to a port. Then:

pub is a file descriptor now connected to epmd. Epmd monitors the other end of the connection, and if it detects that the connection has been closed, the node will be unregistered. So, if you explicitly close the descriptor or if your node fails, it will be unregistered from epmd.

Be aware that on some systems (such as VxWorks), a failed node will not be detected by this mechanism since the operating system does not automatically close descriptors that were left open when the node failed. If a node has failed in this way, epmd will prevent you from registering a new node with the old name, since it thinks that the old name is still in use. In this case, you must unregister the name explicitly:

This will cause epmd to close the connection from the far end. Note that if the name was in fact still in use by a node, the results of this operation are unpredictable. Also, doing this does not cause the local end of the connection to close, so resources may be consumed.

Use one of the following two functions to send messages:

As in Erlang, it is possible to send messages to a Pid or to a registered name. It is easier to send a message to a registered name because it avoids the problem of finding a suitable Pid.

Use one of the following two functions to receive messages:

erl_receive() receives the message into a buffer, while erl_receive_msg() decodes the message into an Erlang term.

An Erlang node acting as a client to another Erlang node typically sends a request and waits for a reply. Such a request is included in a function call at a remote node and is called a remote procedure call. The following example shows how the Erl_Interface library supports remote procedure calls:

c:c/1 is called to compile the specified module on the remote node. erl_match() checks that the compilation was successful by testing for the expected ok.

Refer to the Reference Manual, the erl_connect module for more information about erl_rpc(), and its companions erl_rpc_to() and erl_rpc_from().

A C node has access to names registered through the Erlang Global module. Names can be looked up, allowing the C node to send messages to named Erlang services. C nodes can also register global names, allowing them to provide named services to Erlang processes or other C nodes.

Erl_Interface does not provide a native implementation of the global service. Instead it uses the global services provided by a "nearby" Erlang node. In order to use the services described in this section, it is necessary to first open a connection to an Erlang node.

To see what names there are:

erl_global_names() allocates and returns a buffer containing all the names known to global. count will be initialized to indicate how many names are in the array. The array of strings in names is terminated by a NULL pointer, so it is not necessary to use count to determine when the last name is reached.

It is the caller's responsibility to free the array. erl_global_names() allocates the array and all of the strings using a single call to malloc(), so free(names) is all that is necessary.

To look up one of the names:

If "schedule" is known to global, an Erlang pid is returned that can be used to send messages to the schedule service. Additionally, node will be initialized to contain the name of the node where the service is registered, so that you can make a connection to it by simply passing the variable to erl_connect().

Before registering a name, you should already have registered your port number with epmd. This is not strictly necessary, but if you neglect to do so, then other nodes wishing to communicate with your service will be unable to find or connect to your process.

Create a pid that Erlang processes can use to communicate with your service:

After registering the name, you should use erl_accept() to wait for incoming connections.

Do not forget to free pid later with erl_free_term()!

To unregister a name:

This section describes the use of the registry, a simple mechanism for storing key-value pairs in a C-node, as well as backing them up or restoring them from a Mnesia table on an Erlang node. More detailed information about the individual API functions can be found in the Reference Manual.

Keys are strings, i.e. NULL-terminated arrays of characters, and values are arbitrary objects. Although integers and floating point numbers are treated specially by the registry, you can store strings or binary objects of any type as pointers.

To start, you need to open a registry:

The number 45 in the example indicates the approximate number of objects that you expect to store in the registry. Internally the registry uses hash tables with collision chaining, so there is no absolute upper limit on the number of objects that the registry can contain, but if performance or memory usage are important, then you should choose a number accordingly. The registry can be resized later.

You can open as many registries as you like (if memory permits).

Objects are stored and retrieved through set and get functions. In the following examples you see how to store integers, floats, strings and arbitrary binary objects:

If you attempt to store an object in the registry and there is an existing object with the same key, the new value will replace the old one. This is done regardless of whether the new object and the old one have the same type, so you can, for example, replace a string with an integer. If the existing value is a string or binary, it will be freed before the new value is assigned.

Stored values are retrieved from the registry as follows:

In all of the above examples, the object must exist and it must be of the right type for the specified operation. If you do not know the type of a given object, you can ask:

Buf will be initialized to contain object attributes.

Objects can be removed from the registry:

When you are finished with a registry, close it to remove all the objects and free the memory back to the system: