A NIF library contains native implementation of some functions of an Erlang module. The native implemented functions (NIFs) are called like any other functions without any difference to the caller. Each NIF must also have an implementation in Erlang that will be invoked if the function is called before the NIF library has been successfully loaded. A typical such stub implementation is to throw an exception. But it can also be used as a fallback implementation if the NIF library is not implemented for some architecture.
Use this functionality with extreme care!
A native function is executed as a direct extension of the native code of the VM. Execution is not made in a safe environment. The VM can not provide the same services as provided when executing Erlang code, such as preemptive scheduling or memory protection. If the native function doesn't behave well, the whole VM will misbehave.
A native function that crash will crash the whole VM.
An erroneously implemented native function might cause a VM internal state inconsistency which may cause a crash of the VM, or miscellaneous misbehaviors of the VM at any point after the call to the native function.
A native function that do
A minimal example of a NIF library can look like this:
/* niftest.c */
#include "erl_nif.h"
static ERL_NIF_TERM hello(ErlNifEnv* env, int argc, const ERL_NIF_TERM argv[])
{
return enif_make_string(env, "Hello world!", ERL_NIF_LATIN1);
}
static ErlNifFunc nif_funcs[] =
{
{"hello", 0, hello}
};
ERL_NIF_INIT(niftest,nif_funcs,NULL,NULL,NULL,NULL)
and the Erlang module would have to look something like this:
-module(niftest).
-export([init/0, hello/0]).
init() ->
erlang:load_nif("./niftest", 0).
hello() ->
"NIF library not loaded".
and compile and test something like this (on Linux):
$> gcc -fPIC -shared -o niftest.so niftest.c -I $ERL_ROOT/usr/include/
$> erl
1> c(niftest).
{ok,niftest}
2> niftest:hello().
"NIF library not loaded"
3> niftest:init().
ok
4> niftest:hello().
"Hello world!"
A better solution for a real module is to take advantage of
the new directive
A NIF does not have to be exported, it can be local to the module. Note however that unused local stub functions will be optimized away by the compiler causing loading of the NIF library to fail.
A loaded NIF library is tied to the Erlang module code version
that loaded it. If the module is upgraded with a new version, the
new Erlang code will have to load its own NIF library (or maybe choose not
to). The new code version can however choose to load the exact
same NIF library as the old code if it wants to. Sharing the same
dynamic library will mean that static data defined by the library
will be shared as well. To avoid unintentionally shared static
data, each Erlang module code can keep its own private data. This
private data can be set when the NIF library is loaded and
then retrieved by calling
There is no way to explicitly unload a NIF library. A library will be automatically unloaded when the module code that it belongs to is purged by the code server.
All functions that a NIF library needs to do with Erlang are performed through the NIF API functions. There are functions for the following functionality:
Any Erlang terms can be passed to a NIF as function arguments and
be returned as function return values. The terms are of C-type
All terms of type
Terms of type binary are accessed with the help of the struct type
The raw data pointed to by
Binaries are sequences of whole bytes. Bitstrings with an arbitrary bit length have no support yet.
The use of resource objects is a safe way to return pointers to
native data structures from a NIF. A resource object is
just a block of memory allocated with
All resource objects are created as instances of some resource type.
This makes resources from different modules to be distinguishable.
A resource type is created by calling
Here is a template example of how to create and return a resource object.
ERL_NIF_TERM term;
MyStruct* obj = enif_alloc_resource(my_resource_type, sizeof(MyStruct));
/* initialize struct ... */
term = enif_make_resource(env, obj);
if (keep_a_reference_of_our_own) {
/* store 'obj' in static variable, private data or other resource object */
}
else {
enif_release_resource(obj);
/* resource now only owned by "Erlang" */
}
return term;
Note that once
Another usage of resource objects is to create binary terms with
user defined memory management.
Resource types support upgrade in runtime by allowing a loaded NIF library to takeover an already existing resource type and thereby "inherit" all existing objects of that type. The destructor of the new library will thereafter be called for the inherited objects and the library with the old destructor function can be safely unloaded. Existing resource objects, of a module that is upgraded, must either be deleted or taken over by the new NIF library. The unloading of a library will be postponed as long as there exist resource objects with a destructor function in the library.
A NIF is thread-safe without any explicit synchronization as
long as it acts as a pure function and only reads the supplied
arguments. As soon as you write towards a shared state either through
static variables or
The library initialization callbacks
When a NIF library is built, information about NIF API version
is compiled into the library. When a NIF library is loaded the
runtime system verifies that the library is of a compatible version.
The runtime system will normally refuse to load a NIF library if the major versions differ, or if the major versions are equal and the minor version used by the NIF library is greater than the one used by the runtime system. Old NIF libraries with lower major versions will however be allowed after a bump of the major version during a transition period of two major releases. Such old NIF libraries might however fail if deprecated features are used.
Support for time measurement in NIF libraries:
As mentioned in the
The
If the NIF call is too lengthy one needs to handle this in one of the following ways in order to avoid degraded responsiveness, scheduler load balancing problems, and other strange behaviors:
If the functionality of a long-running NIF can be split so that
its work can be achieved through a series of shorter NIF calls,
the application can either make that series of NIF calls from the
Erlang level, or it can call a NIF that first performs a chunk of
the work, then invokes the
This approach is always preferred over the other alternatives described below. This both from a performance perspective and a system characteristics perspective.
This is accomplished by dispatching the work to another thread
managed by the NIF library, return from the NIF, and wait for the
result. The thread can send the result back to the Erlang
process using
The dirty NIF functionality described here
is experimental. Dirty NIF support is available only when
the emulator is configured with dirty schedulers enabled. This
feature is currently disabled by default. The Erlang runtime
without SMP support do not support dirty schedulers even when
the dirty scheduler support has been enabled. To check at
runtime for the presence of dirty scheduler threads, code can
use the
A NIF that cannot be split and cannot execute in a millisecond or
less is called a "dirty NIF" because it performs work that the
Erlang runtime cannot handle cleanly. Applications that make use
of such functions must indicate to the runtime that the functions
are dirty so they can be handled specially. To schedule a dirty
NIF for execution, the appropriate flags value can be set for the
NIF in its
While a process is executing a dirty NIF some operations that
communicate with it may take a very long time to complete.
Suspend, or garbage collection of a process executing a dirty
NIF cannot be done until the dirty NIF has returned, so other
processes waiting for such operations to complete might have to
wait for a very long time. Blocking multi scheduling, i.e.,
calling
A lot of operations communicating with a process executing a
dirty NIF can, however, complete while it is executing the
dirty NIF. For example, retrieving information about it via
Termination of a process executing a dirty NIF can only be
completed up to a certain point while it is executing the
dirty NIF. All Erlang resources such as its registered name,
its ETS tables, etc will be released. All links and monitors
will be triggered. The actual execution of the NIF will
however not be stopped. The NIF can safely continue
execution, allocate heap memory, etc, but it is of course better
to stop executing as soon as possible. The NIF can check
whether current process is alive or not using
Currently known issues that are planned to be fixed:
Since purging of a module currently might need to garbage collect a process in order to determine if it has references to the module, a process executing a dirty NIF might delay purging for a very long time. Delaying a purge operation implies delaying all code loading operations which might cause severe problems for the system as a whole.
This is the magic macro to initialize a NIF library. It should be evaluated in global file scope.
If compiling a nif for static inclusion via --enable-static-nifs you have to define STATIC_ERLANG_NIF before the ERL_NIF_INIT declaration.
The library will fail to load if
Works the same as
The library will fail to load if
The reload mechanism is deprecated. It was only intended
as a development feature. Do not use it as an upgrade method for
live production systems. It might be removed in future releases. Be sure
to pass
Works the same as
The library will fail to load if
Variables of type
A process bound environment is passed as the first argument to all NIFs. All function arguments passed to a NIF will belong to that environment. The return value from a NIF must also be a term belonging to the same environment. In addition a process bound environment contains transient information about the calling Erlang process. The environment is only valid in the thread where it was supplied as argument until the NIF returns. It is thus useless and dangerous to store pointers to process bound environments between NIF calls.
A process independent environment is created by calling
All contained terms of a list/tuple/map must belong to the same
environment as the list/tuple/map itself. Terms can be copied between
environments with
typedef struct {
const char* name;
unsigned arity;
ERL_NIF_TERM (*fptr)(ErlNifEnv* env, int argc, const ERL_NIF_TERM argv[]);
unsigned flags;
} ErlNifFunc;
Describes a NIF by its name, arity and implementation.
If one of the
typedef struct {
unsigned size;
unsigned char* data;
} ErlNifBinary;
Note that
An enumeration of the options that can be given to
Use this option when receiving data from untrusted sources.
Each instance of
typedef void ErlNifResourceDtor(ErlNifEnv* env, void* obj);
The function prototype of a resource destructor function.
typedef enum {
ERL_NIF_LATIN1
}ErlNifCharEncoding;
The character encoding used in strings and atoms. The only
supported encoding is currently
Used by
A native signed 64-bit integer type.
A native unsigned 64-bit integer type.
A signed 64-bit integer type for representation of time.
An enumeration of time units supported by the NIF API:
Seconds
Milliseconds
Microseconds
Nanoseconds
An enumeration of the properties that can be requested from
Return only positive integers
Return only
Allocate memory of
Allocate a new binary of size
Return true on success or false if allocation failed.
Allocate a new process independent environment. The environment can
be used to hold terms that is not bound to any process. Such terms can
later be copied to a process environment with
Return pointer to the new environment.
Allocate a memory managed resource object of type
Free all terms in an environment and clear it for reuse. The environment must
have been allocated with
Create a term that is the result of decoding the binary data
at
On success, store the resulting term at
See also:
Return an integer less than, equal to, or greater than
zero if
Same as
Same as
Same as
Same as
Same as
Give the runtime system a hint about how much CPU time the current NIF call has consumed
since last hint, or since the start of the NIF if no previous hint has been given.
The time is given as a
Note that it is up to the runtime system to determine if and how to use this information.
Implementations on some platforms may use other means in order to determine consumed
CPU time. Lengthy NIFs should regardless of this frequently call
Returns 1 if the timeslice is exhausted, or 0 otherwise. If 1 is returned the NIF should return as soon as possible in order for the process to yield.
Argument
This function is provided to better support co-operative scheduling, improve system responsiveness,
and make it easier to prevent misbehaviors of the VM due to a NIF monopolizing a scheduler thread.
It can be used to divide
Arguments:
Converts the
Returns
See also:
Returns the CPU time in the same format as
Same as
Free memory allocated by
Free an environment allocated with
Write a null-terminated string, in the buffer pointed to by
Set
Set
Set
Set
If
If
Set
Set
Set
Set
Set
Set
Return true on success or false if
Write a null-terminated string, in the buffer pointed to by
If
Return true on success or false if
Set
Set
Set
Same as
Return true if a pending exception is associated
with the environment
See also:
Initialize the structure pointed to by
Initialize the structure pointed to by
Return true if
Return true if
Return true if currently executing process is currently alive; otherwise false.
This function can only be used from a NIF-calling thread, and with an environment corresponding to currently executing processes.
Return true if
Return true if
Return true if
Return true if
Return true if
Return true if the two terms are identical. Corresponds to the
Erlang operators
Return true if
Return true if
Return true if
This function is only thread-safe when the emulator with SMP support is used. It can only be used in a non-SMP emulator from a NIF-calling thread.
Return true if
This function is only thread-safe when the emulator with SMP support is used. It can only be used in a non-SMP emulator from a NIF-calling thread.
Return true if
Return true if
Return true if
Add a reference to resource object
Create an atom term from the null-terminated C-string
Create an atom term from the string
Make a badarg exception to be returned from a NIF, and associate
it with the environment
See also:
In earlier versions (older than erts-7.0, OTP 18) the return value
from
Make a binary term from
Make a copy of term
Create a floating-point term from a
Try to create the term of an already existing atom from
the null-terminated C-string
Try to create the term of an already existing atom from the
string
Create an integer term.
Create an integer term from a signed 64-bit integer.
Create an ordinary list term of length
Create an ordinary list term with length indicated by the
function name. Prefer these functions (macros) over the variadic
Create a list cell
Create an ordinary list containing the elements of array
Create an integer term from a
Allocate a binary of size
Return a pointer to the raw binary data and set
Make an empty map term.
Make a copy of map
The
Make a copy of map
The
If map
The
Make a pid term from
Create a reference like
Create an opaque handle to a memory managed resource object
obtained by
Note that the only defined behaviour of using a resource term in
an Erlang program is to store it and send it between processes on the
same node. Other operations such as matching or
Create a binary term that is memory managed by a resource object
Several binary terms may be managed by the same resource object. The destructor will not be called until the last binary is garbage collected. This can be useful as a way to return different parts of a larger binary buffer.
As with
Set
The
Create a list containing the characters of the
null-terminated string
Create a list containing the characters of the string
Make a subbinary of binary
Create a tuple term of arity
Create a tuple term with length indicated by the
function name. Prefer these functions (macros) over the variadic
Create a tuple containing the elements of array
Create an integer term from an
Create an integer term from an unsigned 64-bit integer.
Returns a unique integer with the same properties as given by
See also:
Create an integer term from an
Create an iterator for the map
A map iterator is only useful during the lifetime of the environment
ERL_NIF_TERM key, value;
ErlNifMapIterator iter;
enif_map_iterator_create(env, my_map, &iter, ERL_NIF_MAP_ITERATOR_FIRST);
while (enif_map_iterator_get_pair(env, &iter, &key, &value)) {
do_something(key,value);
enif_map_iterator_next(env, &iter);
}
enif_map_iterator_destroy(env, &iter);
The key-value pairs of a map have no defined iteration order. The only guarantee is that the iteration order of a single map instance is preserved during the lifetime of the environment that the map belongs to.
Destroy a map iterator created by
Get key and value terms at current map iterator position.
On success set
Return true if map iterator
Return true if map iterator
Increment map iterator to point to next key-value entry. Return true if the iterator is now positioned at a valid key-value entry, or false if the iterator is positioned at the tail (beyond the last entry).
Decrement map iterator to point to previous key-value entry. Return true if the iterator is now positioned at a valid key-value entry, or false if the iterator is positioned at the head (before the first entry).
Arguments:
Returns the current
Returns
See also:
Same as
Same as
Same as
Same as
Same as
Retuns an
Create or takeover a resource type identified by the string
The two flag values can be combined with bitwise-or. The name of the
resource type is local to the calling module. Argument
On success, return a pointer to the resource type and
Note that
This function works the same as
Using a
This function return true if the command was successfully sent; otherwise,
false. The call may return false if it detects that the command failed for some
reason. For example,
See also:
Return the pointer to the private data that was set by
Was previously named
Create an error exception with the term
See also:
Change the size of a binary
Release a binary obtained from
Remove a reference to resource object
Same as
Same as
Same as
Same as
Same as
Same as
Same as
Same as
Schedule NIF
The
The
The
The calling NIF must use the return value of
Be aware that
Initialize the pid variable
Send a message to a process.
Return true if the message was successfully sent; otherwise, false. The send
operation will fail if
The message environment
If
This function is only thread-safe when the emulator with SMP support is used. It can only be used in a non-SMP emulator from a NIF-calling thread.
Passing
Get the byte size of a resource object
Similar to
Same as
Allocates a new binary with
Returns true on success or false if allocation failed.
See also:
Same as
Same as
Same as
Same as
Same as
Same as
Determine the type of currently executing thread. A positive value indicates a scheduler thread while a negative value or zero indicates another type of thread. Currently the following specific types exist (which may be extended in the future):
Undefined thread that is not a scheduler thread.
A normal scheduler thread.
A dirty CPU scheduler thread.
A dirty I/O scheduler thread.
Arguments:
Returns the current time offset between
Returns
See also:
Same as
Same as
Same as
Same as