The Erl_Interface library contains functions that help you integrate programs written in C and Erlang. The functions in Erl_Interface support the following:

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. To find this, start Erlang and enter the following command at the Eshell prompt:

To compile your code, ensure that your C compiler knows where to find erl_interface.h by specifying an appropriate -I argument on the command line, or add it to the CFLAGS definition in your Makefile. The correct value for this path is $OTPROOT/lib/erl_interface-$EIVSN/include, where:

Compiling the code:

When linking:

Do this on the command line or add the flags to the LDFLAGS definition in your Makefile.

Linking the code:

On some systems it can be necessary to link with some more libraries (for example, libnsl.a and libsocket.a on Solaris, or wsock32.lib on Windows) to use the communication facilities of Erl_Interface.

If you use the 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. You must specify extra compiler flags to indicate which of the packages you use. Define _REENTRANT and either STHREADS or PTHREADS. The default is to use POSIX threads if _REENTRANT is specified.

Before calling any of the other functions in the erl_interface and ei libraries, call erl_init() exactly once to initialize both libraries. erl_init() takes two arguments. However, the arguments are no longer used by erl_interface and are therefore to be specified as erl_init(NULL,0).

If you only use the ei library, instead initialize it by calling ei_init() exactly once before calling any other functions in the ei library.

Data sent between distributed Erlang nodes is encoded in the Erlang external format. You must therefore 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 several C functions that create and manipulate Erlang data structures. The library also contains an encode and a decode function. The following example 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.

For a complete description, see the following modules:

An Erlang pattern is a term that can 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:

The erl_format:erl_match function performs 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, a pattern is created with a variable Age, which is included at two positions in the tuple. The pattern match is performed as follows:

For more information, see the erl_format:erl_match function.

To connect to a distributed Erlang node, you must first initialize the connection routine with erl_connect:erl_connect_init, which stores information, such as the hostname, node name, and IP address for later use:

For more information, see the erl_connect module.

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

erl_err_quit() prints the specified string and terminates the program. For more information, see the erl_error module.

erts:epmd is the Erlang Port Mapper Daemon. Distributed Erlang nodes register with epmd on the local host 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 to find 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 must 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. If it detects that the connection has been closed, the node becomes unregistered. So, if you explicitly close the descriptor or if your node fails, it becomes unregistered from epmd.

Notice that on some systems (such as VxWorks), a failed node is not detected by this mechanism, as 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 prevents you from registering a new node with the old name, as it thinks that the old name is still in use. In this case, you must unregister the name explicitly:

This causes epmd to close the connection from the far end. Notice 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 can be consumed.

Use one of the following two functions to send messages:

As in Erlang, messages can be sent to a pid or to a registered name. It is easier to send a message to a registered name, as 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.

For more information about erl_rpc() and its companions erl_rpc_to() and erl_rpc_from(), see the erl_connect module.

A C node has access to names registered through the global module in Kernel. 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. 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:erl_global_names allocates and returns a buffer containing all the names known to the global module in Kernel. count is initialized to indicate the number of names 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 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 the global module in Kernel, an Erlang pid is returned that can be used to send messages to the schedule service. Also, node is 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 cannot find or connect to your process.

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

After registering the name, use erl_connect:erl_accept to wait for incoming connections.

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 an Mnesia table on an Erlang node. For more detailed information about the individual API functions, see the registry module.

Keys are strings, that is, 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, 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 is important, then you are to 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. The following example shows how to store integers, floats, strings, and arbitrary binary objects:

If you try to store an object in the registry and there is an existing object with the same key, the new value replaces 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 is freed before the new value is assigned.

Stored values are retrieved from the registry as follows:

In all 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 an object, you can ask:

Buf is 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: