erl_nif

API functions for an Erlang NIF library

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.

Warning!

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 lengthy
work before returning will degrade responsiveness of the VM,
and may cause miscellaneous strange behaviors. Such strange behaviors
include, but are not limited to, extreme memory usage, and bad load
balancing between schedulers. Strange behaviors that might occur due
to lengthy work may also vary between OTP releases.

The NIF concept is officially supported from R14B. NIF source code
written for earlier experimental versions might need adaption to run on R14B
or later versions:

No incompatible changes between R14B and R14A.Incompatible changes between R14A and R13B04:
Environment argument removed for enif_alloc,
enif_realloc, enif_free, enif_alloc_binary,
enif_realloc_binary, enif_release_binary,
enif_alloc_resource, enif_release_resource,
enif_is_identical and enif_compare.Character encoding argument added to enif_get_atom
and enif_make_existing_atom.Module argument added to enif_open_resource_type
while changing name spaces of resource types from global to module local.Incompatible changes between R13B04 and R13B03:
The function prototypes of the NIFs have changed to expect argc and argv
arguments. The arity of a NIF is by that no longer limited to 3.enif_get_data renamed as enif_priv_data.enif_make_string got a third argument for character encoding.

A better solution for a real module is to take advantage of
the new directive on_load to automatically
load the NIF library when the module is loaded.

Note!

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

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.

As mentioned in the warning text at
the beginning of this document it is of vital importance that a native function
does return relatively fast. It is hard to give an exact maximum amount
of time that a native function is allowed to work, but as a rule of thumb
a well behaving native function should return to its caller before a
millisecond has passed. This can be achieved using different approaches.
If you have full control over the code that are to execute in the native
function, the best approach is to divide the work into multiple chunks of
work and call the native function multiple times. Function
enif_consume_timeslice can be
used this facilitate such work division. In some cases, however, this might not
be possible, e.g. when calling third party libraries. Then you typically want
to dispatch the work to another thread, return
from the native function, and wait for the result. The thread can send
the result back to the calling thread using message passing. Information
about thread primitives can be found below. If you have built your system
with the currently experimental support for dirty schedulers,
you may want to try out this functionality by dispatching the work to a
dirty NIF,
which does not have the same duration restriction as a normal NIF.

FUNCTIONALITY

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:

Read and write Erlang terms

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
ERL_NIF_TERM
and can only be read or written using API functions. Most functions to read
the content of a term are prefixed enif_get_ and usually return
true (or false) if the term was of the expected type (or not).
The functions to write terms are all prefixed enif_make_ and usually
return the created ERL_NIF_TERM. There are also some functions
to query terms, like enif_is_atom, enif_is_identical and
enif_compare.

All terms of type ERL_NIF_TERM belong to an environment of type
ErlNifEnv. The lifetime of a term is
controlled by the lifetime of its environment object. All API functions that read
or write terms has the environment, that the term belongs to, as the first
function argument.

Binaries

Terms of type binary are accessed with the help of the struct type
ErlNifBinary
that contains a pointer (data) to the raw binary data and the length
(size) of the data in bytes. Both data and size are
read-only and should only be written using calls to API functions.
Instances of ErlNifBinary are however always allocated by the user
(usually as local variables).

The raw data pointed to by data is only mutable after a call to
enif_alloc_binary or
enif_realloc_binary.
All other functions that operates on a binary will leave the data as read-only.
A mutable binary must in the end either be freed with
enif_release_binary
or made read-only by transferring it to an Erlang term with
enif_make_binary.
But it does not have to happen in the same NIF call. Read-only binaries
do not have to be released.

enif_make_new_binary
can be used as a shortcut to allocate and return a binary in the same NIF call.

Binaries are sequences of whole bytes. Bitstrings with an arbitrary
bit length have no support yet.

Resource objects

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
enif_alloc_resource.
A handle ("safe pointer") to this memory block can then be returned to Erlang by the use of
enif_make_resource.
The term returned by enif_make_resource
is totally opaque in nature. It can be stored and passed between processes
on the same node, but the only real end usage is to pass it back as an argument to a NIF.
The NIF can then call enif_get_resource
and get back a pointer to the memory block that is guaranteed to still be
valid. A resource object will not be deallocated until the last handle term
has been garbage collected by the VM and the resource has been
released with enif_release_resource
(not necessarily in that order).

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
enif_open_resource_type
when a library is loaded. Objects of that resource type can then later be allocated
and enif_get_resource verifies that the resource is of the expected type.
A resource type can have a user supplied destructor function that is
automatically called when resources of that type are released (by either
the garbage collector or enif_release_resource). Resource types
are uniquely identified by a supplied name string and the name of the
implementing module.

Here is a template example of how to create and return a resource object.

Note that once enif_make_resource creates the term to
return to Erlang, the code can choose to either keep its own
native pointer to the allocated struct and release it later, or
release it immediately and rely solely on the garbage collector
to eventually deallocate the resource object when it collects
the term.

Another usage of resource objects is to create binary terms with
user defined memory management.
enif_make_resource_binary
will create a binary term that is connected to a resource object. The
destructor of the resource will be called when the binary is garbage
collected, at which time the binary data can be released. An example of
this can be a binary term consisting of data from a mmap'ed file.
The destructor can then do munmap to release the memory
region.

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.

Threads and concurrency

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 enif_priv_data
you need to supply your own explicit synchronization. This includes terms
in process independent environments that are shared between threads.
Resource objects will also require synchronization if you treat them as
mutable.

The library initialization callbacks load, reload and
upgrade are all thread-safe even for shared state data.

Dirty NIFs

Note that the dirty NIF functionality
is experimental and that you have to enable support for dirty
schedulers when building OTP in order to try the functionality out. Native functions
must normally run quickly, as explained earlier in this document. They
generally should execute for no more than a millisecond. But not all native functions
can execute so quickly; for example, functions that encrypt large blocks of data or
perform lengthy file system operations can often run for tens of seconds or more.

A NIF that cannot execute in a millisecond or less is called a "dirty NIF" since
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
application calls enif_schedule_dirty_nif,
passing to it a pointer to the dirty NIF to be executed and indicating with a flag
argument whether it expects the operation to be CPU-bound or I/O-bound.

All dirty NIFs must ultimately invoke the
enif_schedule_dirty_nif_finalizer as their final action, passing to it the
result they wish to return to the original caller. A finalizer function can either
receive the result and return it directly, or it can return a different value instead.
For convenience, the NIF API provides the
enif_dirty_nif_finalizer function that applications can use as a finalizer;
it simply returns its result argument.

Note!

Dirty NIF support is available only when the emulator is configured with dirty
schedulers enabled. This feature is currently disabled by default. To determine whether
the dirty NIF API is available, native code can check to see if the C preprocessor macro
ERL_NIF_DIRTY_SCHEDULER_SUPPORT is defined. Also, if the Erlang runtime was built
without threading support, dirty schedulers are disabled. To check at runtime for the presence
of dirty scheduler threads, code can call the
enif_have_dirty_schedulers() API function, which returns true if dirty
scheduler threads are present, false otherwise.

INITIALIZATION

This is the magic macro to initialize a NIF library. It
should be evaluated in global file scope.

MODULE is the name of the Erlang module as an
identifier without string quotations. It will be stringified by
the macro.

funcs is a static array of function descriptors for
all the implemented NIFs in this library.

load, reload, upgrade and unload
are pointers to functions. One of load, reload or
upgrade will be called to initialize the library.
unload is called to release the library. They are all
described individually below.

If compiling a nif for static inclusion via --enable-static-nifs you
have to define STATIC_ERLANG_NIF before the ERL_NIF_INIT declaration.

int (*load)(ErlNifEnv* env, void** priv_data, ERL_NIF_TERM load_info)

load is called when the NIF library is loaded
and there is no previously loaded library for this module.

*priv_data can be set to point to some private data
that the library needs in order to keep a state between NIF
calls. enif_priv_data will return this pointer.
*priv_data will be initialized to NULL when load is
called.

upgrade is called when the NIF library is loaded
and there is old code of this module with a loaded NIF library.

Works the same as load. The only difference is that
*old_priv_data already contains the value set by the
last call to load or reload for the old module
code. *priv_data will be initialized to NULL when upgrade
is called. It is allowed to write to both *priv_data and *old_priv_data.

The library will fail to load if upgrade returns
anything other than 0 or if upgrade is NULL.

void (*unload)(ErlNifEnv* env, void* priv_data)

unload is called when the module code that
the NIF library belongs to is purged as old. New code
of the same module may or may not exist. Note that unload is not
called for a replaced library as a consequence of reload.

Note!

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 reload as NULL to ERL_NIF_INIT
to disable it when not used.

reload is called when the NIF library is loaded
and there is already a previously loaded library for this
module code.

Works the same as load. The only difference is that
*priv_data already contains the value set by the
previous call to load or reload.

The library will fail to load if reload returns
anything other than 0 or if reload is NULL.

DATA TYPES

ERL_NIF_TERM

Variables of type ERL_NIF_TERM can refer to any Erlang term.
This is an opaque type and values of it can only by used either as
arguments to API functions or as return values from NIFs. All
ERL_NIF_TERM's belong to an environment
(ErlNifEnv). A term can not be
destructed individually, it is valid until its environment is destructed.

ErlNifEnv

ErlNifEnv represents an environment that can host Erlang terms.
All terms in an environment are valid as long as the environment is valid.
ErlNifEnv is an opaque type and pointers to it can only be passed
on to API functions. There are two types of environments; process
bound and process independent.

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
enif_alloc_env. It can be
used to store terms between NIF calls and to send terms with
enif_send. A process
independent environment with all its terms is valid until you explicitly
invalidates it with enif_free_env
or enif_send.

All elements of a list/tuple must belong to the same environment as the
list/tuple itself. Terms can be copied between environments with
enif_make_copy.

Describes a NIF by its name, arity and implementation.
fptr is a pointer to the function that implements the
NIF. The argument argv of a NIF will contain the
function arguments passed to the NIF and argc is the
length of the array, i.e. the function arity. argv[N-1]
will thus denote the Nth argument to the NIF. Note that the
argc argument allows for the same C function to
implement several Erlang functions with different arity (but
same name probably).

ErlNifBinary

typedef struct {
unsigned size;
unsigned char* data;
} ErlNifBinary;

ErlNifBinary contains transient information about an
inspected binary term. data is a pointer to a buffer
of size bytes with the raw content of the binary.

Note that ErlNifBinary is a semi-opaque type and you are
only allowed to read fields size and data.

ErlNifPid

ErlNifPid is a process identifier (pid). In contrast to
pid terms (instances of ERL_NIF_TERM), ErlNifPid's are self
contained and not bound to any
environment. ErlNifPid
is an opaque type.

ErlNifResourceType

Each instance of ErlNifResourceType represent a class of
memory managed resource objects that can be garbage collected.
Each resource type has a unique name and a destructor function that
is called when objects of its type are released.

ErlNifResourceDtor

typedef void ErlNifResourceDtor(ErlNifEnv* env, void* obj);

The function prototype of a resource destructor function.
A destructor function is not allowed to call any term-making functions.

ErlNifCharEncoding

typedef enum {
ERL_NIF_LATIN1
}ErlNifCharEncoding;

The character encoding used in strings and atoms. The only
supported encoding is currently ERL_NIF_LATIN1 for
iso-latin-1 (8-bit ascii).

Allocate a new binary of size size
bytes. Initialize the structure pointed to by bin to
refer to the allocated binary. The binary must either be released by
enif_release_binary
or ownership transferred to an Erlang term with
enif_make_binary.
An allocated (and owned) ErlNifBinary can be kept between NIF
calls.

Return true on success or false if allocation failed.

ErlNifEnv * enif_alloc_env()

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
enif_make_copy
or be sent to a process as a message with enif_send.

Free all terms in an environment and clear it for reuse. The environment must
have been allocated with enif_alloc_env.

int enif_compare(ERL_NIF_TERM lhs, ERL_NIF_TERM rhs)

Return an integer less than, equal to, or greater than
zero if lhs is found, respectively, to be less than,
equal, or greater than rhs. Corresponds to the Erlang
operators ==, /=, =<, <,
>= and > (but not=:= or =/=).

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 percent of the timeslice that a process is allowed to execute Erlang
code until it may be suspended to give time for other runnable processes.
The scheduling timeslice is not an exact entity, but can usually be
approximated to about 1 millisecond.

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 enif_consume_timeslice
in order to determine if it is allowed to continue execution or not.

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 percent must be an integer between 1 and 100. This function
must only be called from a NIF-calling thread and argument env must be
the environment of the calling process.

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 length work into
a number of repeated NIF-calls without the need to create threads.
See also the warning text at the beginning of this document.

A convenience function that a dirty NIF can use as a finalizer that simply
return its result argument as its return value. This function is provided
for dirty NIFs with results that should be returned directly to the original caller.

Note!

This function is available only when the emulator is configured with dirty
schedulers enabled. This feature is currently disabled by default. To determine whether
the dirty NIF API is available, native code can check to see if the C preprocessor macro
ERL_NIF_DIRTY_SCHEDULER_SUPPORT is defined.

Write a null-terminated string, in the buffer pointed to by
buf of size size, consisting of the string
representation of the atom term with encoding
encode. Return
the number of bytes written (including terminating null character) or 0 if
term is not an atom with maximum length of
size-1.

Write a null-terminated string, in the buffer pointed to by
buf with size size, consisting of the characters
in the string list. The characters are written using encoding
encode.
Return the number of bytes written (including terminating null
character), or -size if the string was truncated due to
buffer space, or 0 if list is not a string that can be
encoded with encode or if size was less than 1.
The written string is always null-terminated unless buffer
size is less than 1.

If term is a tuple, set *array to point
to an array containing the elements of the tuple and set
*arity to the number of elements. Note that the array
is read-only and (*array)[N-1] will be the Nth element of
the tuple. *array is undefined if the arity of the tuple
is zero.

Set *ip to the unsigned long integer value of term
and return true, or return false if term is not an unsigned integer or is
outside the bounds of type unsigned long.

int enif_have_dirty_schedulers()

Check at runtime for the presence of dirty scheduler threads. If the emulator is
built with threading support, dirty scheduler threads are available and
enif_have_dirty_schedulers() returns true. If the emulator was built without
threading support, enif_have_dirty_schedulers() returns false.

If dirty scheduler threads are not available in the emulator, calls to
enif_schedule_dirty_nif and enif_schedule_dirty_nif_finalizer result in
the NIF and finalizer functions being called directly within the calling thread.

Note!

This function is available only when the emulator is configured with dirty
schedulers enabled. This feature is currently disabled by default. To determine whether
the dirty NIF API is available, native code can check to see if the C preprocessor macro
ERL_NIF_DIRTY_SCHEDULER_SUPPORT is defined.

Initialize the structure pointed to by bin with one
continuous buffer with the same byte content as iolist. As with
inspect_binary, the data pointed to by bin is transient and does
not need to be released. Return true on success or false if iolist is not an
iolist.

int enif_is_atom(ErlNifEnv* env, ERL_NIF_TERM term)

Return true if term is an atom.

int enif_is_binary(ErlNifEnv* env, ERL_NIF_TERM term)

Return true if term is a binary

int enif_is_empty_list(ErlNifEnv* env, ERL_NIF_TERM term)

Return true if term is an empty list.

int enif_is_exception(ErlNifEnv* env, ERL_NIF_TERM term)

Return true if term is an exception.

int enif_is_number(ErlNifEnv* env, ERL_NIF_TERM term)

Return true if term is a number.

int enif_is_fun(ErlNifEnv* env, ERL_NIF_TERM term)

Return true if term is a fun.

int enif_is_identical(ERL_NIF_TERM lhs, ERL_NIF_TERM rhs)

Return true if the two terms are identical. Corresponds to the
Erlang operators =:= and
=/=.

int enif_is_on_dirty_scheduler(ErlNifEnv* env)

Check to see if the current NIF is executing on a dirty scheduler thread. If the
emulator is built with threading support, calling enif_is_on_dirty_scheduler
from within a dirty NIF returns true. It returns false when the calling NIF is a regular
NIF or a NIF finalizer, both of which run on normal scheduler threads, or when the emulator
is built without threading support.

Note!

This function is available only when the emulator is configured with dirty
schedulers enabled. This feature is currently disabled by default. To determine whether
the dirty NIF API is available, native code can check to see if the C preprocessor macro
ERL_NIF_DIRTY_SCHEDULER_SUPPORT is defined.

int enif_is_pid(ErlNifEnv* env, ERL_NIF_TERM term)

Return true if term is a pid.

int enif_is_port(ErlNifEnv* env, ERL_NIF_TERM term)

Return true if term is a port.

int enif_is_ref(ErlNifEnv* env, ERL_NIF_TERM term)

Return true if term is a reference.

int enif_is_tuple(ErlNifEnv* env, ERL_NIF_TERM term)

Return true if term is a tuple.

int enif_is_list(ErlNifEnv* env, ERL_NIF_TERM term)

Return true if term is a list.

int enif_keep_resource(void* obj)

Add a reference to resource object obj obtained from
enif_alloc_resource.
Each call to enif_keep_resource for an object must be balanced by
a call to enif_release_resource
before the object will be destructed.

ERL_NIF_TERM enif_make_atom(ErlNifEnv* env, const char* name)

Create an atom term from the null-terminated C-string name
with iso-latin-1 encoding.

Create an atom term from the string name with length len.
Null-characters are treated as any other characters.

ERL_NIF_TERM enif_make_badarg(ErlNifEnv* env)

Make a badarg exception to be returned from a NIF, and set
an associated exception reason in env. If
enif_make_badarg is called, the term it returns must
be returned from the function that called it. No other return value
is allowed. Also, the term returned from enif_make_badarg may
be passed only to
enif_is_exception and
not to any other NIF API function.

ERL_NIF_TERM enif_make_binary(ErlNifEnv* env, ErlNifBinary* bin)

Make a binary term from bin. Any ownership of
the binary data will be transferred to the created term and
bin should be considered read-only for the rest of the NIF
call and then as released.

Try to create the term of an already existing atom from
the null-terminated C-string name with encoding
encode. If the atom
already exists store the term in *atom and return true, otherwise
return false.

Try to create the term of an already existing atom from the
string name with length len and encoding
encode. Null-characters
are treated as any other characters. If the atom already exists store the term
in *atom and return true, otherwise return false.

ERL_NIF_TERM enif_make_int(ErlNifEnv* env, int i)

Create an integer term.

ERL_NIF_TERM enif_make_int64(ErlNifEnv* env, ErlNifSInt64 i)

Create an integer term from a signed 64-bit integer.

ERL_NIF_TERM enif_make_list(ErlNifEnv* env, unsigned cnt, ...)

Create an ordinary list term of length cnt. Expects
cnt number of arguments (after cnt) of type ERL_NIF_TERM as the
elements of the list. An empty list is returned if cnt is 0.

Create an ordinary list term with length indicated by the
function name. Prefer these functions (macros) over the variadic
enif_make_list to get a compile time error if the number of
arguments does not match.

Set *list to the reverse list of the list term and return true,
or return false if term is not a list. This function should only be used on
short lists as a copy will be created of the list which will not be released until after the
nif returns.

Allocate a binary of size size bytes and create an owning
term. The binary data is mutable until the calling NIF returns. This is a
quick way to create a new binary without having to use
ErlNifBinary. The drawbacks are
that the binary can not be kept between NIF calls and it can not be
reallocated.

Return a pointer to the raw binary data and set
*termp to the binary term.

Create an opaque handle to a memory managed resource object
obtained by enif_alloc_resource.
No ownership transfer is done, as the resource object still needs to be released by
enif_release_resource,
but note that the call to enif_release_resource can occur
immediately after obtaining the term from enif_make_resource,
in which case the resource object will be deallocated when the
term is garbage collected. See the
example of creating and
returning a resource object for more details.

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 term_to_binary
will have unpredictable (but harmless) results.

Create a binary term that is memory managed by a resource object
obj obtained by enif_alloc_resource.
The returned binary term will consist of size bytes pointed to
by data. This raw binary data must be kept readable and unchanged
until the destructor of the resource is called. The binary data may be
stored external to the resource object in which case it is the responsibility
of the destructor to release the data.

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.

Make a subbinary of binary bin_term, starting at
zero-based position pos with a length of size bytes.
bin_term must be a binary or bitstring and
pos+size must be less or equal to the number of whole
bytes in bin_term.

ERL_NIF_TERM enif_make_tuple(ErlNifEnv* env, unsigned cnt, ...)

Create a tuple term of arity cnt. Expects
cnt number of arguments (after cnt) of type ERL_NIF_TERM as the
elements of the tuple.

Create or takeover a resource type identified by the string
name and give it the destructor function pointed to by dtor.
Argument flags can have the following values:

ERL_NIF_RT_CREATE

Create a new resource type that does not already exist.

ERL_NIF_RT_TAKEOVER

Open an existing resource type and take over ownership of all its instances.
The supplied destructor dtor will be called both for existing instances
as well as new instances not yet created by the calling NIF library.

The two flag values can be combined with bitwise-or. The name of the
resource type is local to the calling module. Argument module_str
is not (yet) used and must be NULL. The dtor may be NULL
in case no destructor is needed.

On success, return a pointer to the resource type and *tried
will be set to either ERL_NIF_RT_CREATE or
ERL_NIF_RT_TAKEOVER to indicate what was actually done.
On failure, return NULL and set *tried to flags.
It is allowed to set tried to NULL.

Note that enif_open_resource_type is only allowed to be called in the three callbacks
load, reload
and upgrade.

void * enif_priv_data(ErlNifEnv* env)

Return the pointer to the private data that was set by load,
reload or upgrade.

Was previously named enif_get_data.

int enif_realloc_binary(ErlNifBinary* bin, size_t size)

Change the size of a binary bin. The source binary
may be read-only, in which case it will be left untouched and
a mutable copy is allocated and assigned to *bin. Return true on success,
false if memory allocation failed.

void enif_release_binary(ErlNifBinary* bin)

Release a binary obtained from enif_alloc_binary.

void enif_release_resource(void* obj)

Remove a reference to resource object objobtained from
enif_alloc_resource.
The resource object will be destructed when the last reference is removed.
Each call to enif_release_resource must correspond to a previous
call to enif_alloc_resource or
enif_keep_resource.
References made by enif_make_resource
can only be removed by the garbage collector.

Schedule dirty NIF fp to execute a long-running operation. The flags
argument must be set to either ERL_NIF_DIRTY_JOB_CPU_BOUND if the job is expected to
be primarily CPU-bound, or ERL_NIF_DIRTY_JOB_IO_BOUND for jobs that will be
I/O-bound. The argc and argv arguments can either be the originals passed
into the calling NIF, or they can be values created by the calling NIF. The calling
NIF must use the return value of enif_schedule_dirty_nif as its own return value.

Be aware that enif_schedule_dirty_nif, as its name implies, only schedules the
dirty NIF for future execution. The calling NIF does not block waiting for the dirty NIF to
execute and return, which means that the calling NIF can't expect to receive the dirty NIF
return value and use it for further operations.

A dirty NIF may not invoke the enif_make_badarg
to raise an exception. If it wishes to return an exception, the dirty NIF should pass a
regular result indicating the exception details to its finalizer, and allow the finalizer
to raise the exception on its behalf.

Note!

This function is available only when the emulator is configured with dirty schedulers
enabled. This feature is currently disabled by default. To determine whether the dirty NIF API
is available, native code can check to see if the C preprocessor macro
ERL_NIF_DIRTY_SCHEDULER_SUPPORT is defined.

When a dirty NIF finishes executing, it must schedule a finalizer function to return
its result to the original NIF caller. The dirty NIF passes result as the value it
wants the finalizer to use as the return value. The fp argument is a pointer to the
finalizer function. The NIF API provides the
enif_dirty_nif_finalizer function that can be used as a finalizer that simply
returns its result argument. You are also free to write your own custom finalizer
that uses result to derive a different return value, or ignores result
entirely and returns a completely different value.

Without exception, all dirty NIFs must invoke enif_schedule_dirty_nif_finalizer
to complete their execution.

Note!

This function is available only when the emulator is configured with dirty
schedulers enabled. This feature is currently disabled by default. To determine whether
the dirty NIF API is available, native code can check to see if the C preprocessor macro
ERL_NIF_DIRTY_SCHEDULER_SUPPORT is defined.

The environment of the calling process. Must be NULL if and
only if calling from a created thread.

*to_pid

The pid of the receiving process. The pid should refer to a process on the local node.

msg_env

The environment of the message term. Must be a process
independent environment allocated with
enif_alloc_env.

msg

The message term to send.

Return true on success, or false if *to_pid does not refer to an alive local process.

The message environment msg_env with all its terms (including
msg) will be invalidated by a successful call to enif_send. The environment
should either be freed with enif_free_env
of cleared for reuse with enif_clear_env.

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.