From 57c3246511434f42214e113b8902af10ab9cca49 Mon Sep 17 00:00:00 2001
From: xsipewe 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!
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 native function that crash will crash the whole VM.
+An erroneously implemented native function can cause a VM + internal state inconsistency, which can 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 doing
A minimal example of a NIF library can look as follows:
-A minimal example of a NIF library can look like this:
- -
+
/* niftest.c */
#include "erl_nif.h"
@@ -83,13 +92,11 @@ static ErlNifFunc nif_funcs[] =
{"hello", 0, hello}
};
-ERL_NIF_INIT(niftest,nif_funcs,NULL,NULL,NULL,NULL)
-
+ERL_NIF_INIT(niftest,nif_funcs,NULL,NULL,NULL,NULL)
- and the Erlang module would have to look something like - this:
- -
+ The Erlang module can look as follows:
+
+
-module(niftest).
-export([init/0, hello/0]).
@@ -98,11 +105,11 @@ init() ->
erlang:load_nif("./niftest", 0).
hello() ->
- "NIF library not loaded".
-
- and compile and test something like this (on Linux):
-
-
+ "NIF library not loaded".
+
+ Compile and test can look as follows (on Linux):
+
+
$> gcc -fPIC -shared -o niftest.so niftest.c -I $ERL_ROOT/usr/include/
$> erl
@@ -113,290 +120,310 @@ $> erl
3> niftest:init().
ok
4> niftest:hello().
-"Hello world!"
-
-
- 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.
- 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.
+"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. + However, 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.
- +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 need to load its own NIF library (or maybe choose not
+ to). The new code version can, however, choose to load the
+ same NIF library as the old code if it wants to. Sharing the
+ dynamic library means that static data defined by the library
+ is 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
A NIF library cannot be loaded explicitly. A library is + 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 +
All functions that a NIF library needs to do with Erlang are + performed through the NIF API functions. Functions exist 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
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.
-Terms of type binary are accessed with the help of 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. -
+The use of resource objects is a safe way to return pointers to
+ native data structures from a NIF. A resource object is
+ only 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
+
The following 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;
+ Notice that once
Another use 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 take over an already existing resource type and by that + "inherit" all existing objects of that type. The destructor of the + new library is thereafter 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 is 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
A NIF is thread-safe without any explicit synchronization as
+ long as it acts as a pure function and only reads the supplied
+ arguments. When you write to 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. -
When a NIF library is built, information about the 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.
+
Incremented when NIF library incompatible changes are made to the
+ Erlang runtime system. Normally it suffices to recompile the NIF
+ library when the
Incremented when new features are added. The runtime system uses + the minor version to determine what features to use.
+The runtime system normally refuses 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 are, however, allowed after a bump of the major version + during a transition period of two major releases. Such old NIF + libraries can however fail if deprecated features are used.
+Support for time measurement in NIF libraries:
-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
- ordinary schedulers of the Erlang runtime system 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. This is handled by executing dirty jobs on a separate
+ As mentioned in the The If the NIF call is too lengthy, this must be handled in one of
+ the following ways 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 has two options: Make that series of NIF calls from the Erlang level. Call a NIF that first performs a chunk of the work, then
+ invokes the Breaking up a long-running function in this manner enables the
+ VM to regain control between calls to the NIFs. 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 disabled by default. The Erlang runtime
+ without SMP support does not support dirty schedulers even when
+ the dirty scheduler support is 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", as it performs work that the
+ ordinary schedulers of the Erlang runtime system 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. This is handled by executing dirty jobs on a separate
set of schedulers called dirty schedulers. A dirty NIF executing
on a dirty scheduler does not have the same duration restriction
as a normal NIF.
-
- It is important to classify the dirty job correct. An I/O bound
+
+ It is important to classify the dirty job correct. An I/O bound
job should be classified as such, and a CPU bound job should be
classified as such. If you should classify CPU bound jobs
as I/O bound jobs, dirty I/O schedulers might starve ordinary
@@ -404,1240 +431,1636 @@ ok
for I/O, and/or spend a limited amount of time moving data.
- To schedule a dirty NIF for execution, the appropriate
-
- 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.
-
+ To schedule a dirty NIF for execution, the application has two options: Set the appropriate flags value for the dirty NIF in its
+ Call A job that alternates between I/O bound and CPU bound can be
+ reclassified and rescheduled using While a process executes a dirty NIF, some operations that
+ communicate with it can 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. Thus, other
+ processes waiting for such operations to complete might
+ have to wait for a very long time. Blocking multi-scheduling, that
+ is, calling Many operations communicating with a process executing a
+ dirty NIF can, however, complete while it executes the
+ dirty NIF. For example, retrieving information about it through
+ Termination of a process executing a dirty NIF can only be
+ completed up to a certain point while it executes the dirty NIF.
+ All Erlang resources, such as its registered name and its Known issue that are planned to be fixed: As purging of a module might need to garbage
+ collect a process to determine if it has
+ references to the module, a process executing a dirty
+ NIF can delay purging for a very long time. Delaying
+ a purge operation implies delaying all code
+ loading operations, which can 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.
+This is the magic macro to initialize a NIF library. It + is to be evaluated in global file scope.
+If compiling a NIF for static inclusion through
+
The library will fail to load if
Works the same as
The library will fail to load if
The library fails to load if
Works as
The library fails 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
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 can be removed in future releases.
+ Ensure to pass
Works as
The library fails 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
-
Passed as the first argument to all NIFs. All function arguments + passed to a NIF belong to that environment. The return value from + a NIF must also be a term belonging to the same environment.
+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.
+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
-
+ ErlNifFunc
+ -
+
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.
- 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). For a regular NIF, flags is 0 (and
- so its value can be omitted for statically initialized ErlNifFunc
- instances), or it can be used to indicate that the NIF is a dirty NIF that should be executed
- on a dirty scheduler thread (note that the dirty NIF functionality
- described here is experimental and that you have to enable
- support for dirty schedulers when building OTP in order to try the
- functionality out). If the dirty NIF is expected to be
- CPU-bound, its flags field should be set to
- ERL_NIF_DIRTY_JOB_CPU_BOUND , or for I/O-bound jobs,
- ERL_NIF_DIRTY_JOB_IO_BOUND .
- If one of the
- ERL_NIF_DIRTY_JOB_*_BOUND flags is set, and the runtime
- system has no support for dirty schedulers, the runtime system
- will refuse to load the NIF library.
+} ErlNifFunc;
+ Describes a NIF by its name, arity, and implementation.
+A pointer to the function that implements the NIF.
+Contains the function arguments passed to the NIF.
+The array length, that is, the function arity.
Is
The dirty NIF functionality described here is + experimental. You have to enable support for dirty + schedulers when building OTP to try out the functionality.
+If the dirty NIF is expected to be CPU-bound, its
If one of the
+ ErlNifBinary
+ -
+
typedef struct {
unsigned size;
unsigned char* data;
-} ErlNifBinary;
-
+} ErlNifBinary;
Note that
Notice that
An enumeration of the options that can be given to
-
Use this option when receiving data from untrusted sources.
An enumeration of the options that can be specified to
+
When receiving data from untrusted sources, use option
+
Each instance of A process identifier (pid). In contrast to pid terms (instances of
+ A port identifier. In contrast to port ID terms (instances of
+ Each instance of The function prototype of a resource destructor function. The function prototype of a resource destructor function. 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.
-typedef void ErlNifResourceDtor(ErlNifEnv* env, void* obj);
-
-
+
+typedef void ErlNifResourceDtor(ErlNifEnv* env, void* obj);
+
typedef enum {
ERL_NIF_LATIN1
-}ErlNifCharEncoding;
-
-
The character encoding used in strings and atoms. The only
+ supported encoding is
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
-
Return only positive integers.
+Return only
Allocate memory of
Allocates memory of
Returns
Allocate a new binary of size
Return true on success or false if allocation failed.
+Allocates a new binary of size
Returns
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
Create a term that is the result of decoding the binary data
- at
On success, store the resulting term at
See also:
-
Allocates a new process-independent environment. The environment can
+ be used to hold terms that are not bound to any process. Such terms
+ can later be copied to a process environment with
+
Returns pointer to the new environment.
+Free all terms in an environment and clear it for reuse. The environment must
- have been allocated with
Allocates a memory-managed resource object of type
Return an integer less than, equal to, or greater than
- zero if
Creates a term that is the result of decoding the binary data at
+
On success, stores the resulting term at
See also
Same as
Frees all terms in an environment and clears it for reuse.
+ The environment must have been allocated with
+
Same as
Returns an integer <
Same as
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
Same as
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
Same as
Gives the runtime system a hint about how much CPU time the current + NIF call has consumed since the last hint, or since the start of the + NIF if no previous hint has been specified. The time is specified as a + percent of the timeslice that a process is allowed to execute + Erlang code until it can 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.
+Notice that it is up to the runtime system to determine if and how
+ to use this information. Implementations on some platforms can use
+ other means to determine consumed CPU time. Lengthy NIFs should
+ regardless of this frequently call
Argument
Returns
This function is provided to better support co-operative scheduling,
+ improve system responsiveness, and make it easier to prevent
+ misbehaviors of the VM because of a NIF monopolizing a scheduler
+ thread. It can be used to divide
See also the
Arguments:
-Converts the
Returns
See also:
-
Converts the
Returns
See also
Returns the CPU time in the same format as
Returns the CPU time in the same format as
+
Same as
Same as
Free memory allocated by
Frees memory allocated by
+
Free an environment allocated with
Frees an environment allocated with
+
Write a null-terminated string, in the buffer pointed to by
-
Writes a
Returns the number of bytes written (including terminating
+
Set
Sets
Returns
Set
Sets
Returns
Set
Sets
Returns
Set
Sets
Returns
If
If
If
If
Set
Sets
Returns
Set
Sets
Returns
Set
Sets
Returns
Set
Sets
Returns
Set
Sets
Returns
Set
Return true on success or false if
Sets
Returns
Write a null-terminated string, in the buffer pointed to by
-
Writes a
Returns one of the following:
+The written string is always
If
Return true on success or false if
If
Returns
Set
Sets
Returns
Set
Sets
Returns
Set
Sets
Returns
Same as
Same as
Return true if a pending exception is associated
- with the environment
See also:
Returns
See also
Initialize the structure pointed to by
Initializes the structure pointed to by
Returns
Initialize the structure pointed to by
Initializes the structure pointed to by
Returns
Return true if
Returns
Return true if
Returns
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.
Returns
This function can only be used from a NIF-calling thread, and with + an environment corresponding to currently executing processes.
+Return true if
Returns
Return true if
Return true if
Return true if
Returns
Return true if the two terms are identical. Corresponds to the
- Erlang operators
Returns
Return true if
Returns
Return true if
Returns
Return true if
Returns
Return true if
Returns
Return true if
Returns
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.
Returns
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.
Returns
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
Returns
Return true if
Returns
Add a reference to resource object
Adds a reference to resource object
Create an atom term from the null-terminated C-string
Creates an atom term from the
Create an atom term from the 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
Makes a
The return value from
See also
Before
Make a binary term from
Makes a binary term from
Make a copy of term
Makes a copy of term
Create a floating-point term from a
Creates a floating-point term from a
Try to create the term of an already existing atom from
- the null-terminated C-string
Tries to create the term of an already existing atom from
+ the
If the atom already exists, this function stores the term in
+
Try to create the term of an already existing atom from the
- string
Tries to create the term of an already existing atom from the
+ string
If the atom already exists, this function stores the term in
+
Create an integer term.
Creates an integer term.
+Create an integer term from a signed 64-bit integer.
Creates an integer term from a signed 64-bit integer.
+Create an ordinary list term of length
Creates an ordinary list term of length
Returns an empty list if
Create an ordinary list term with length indicated by the
- function name. Prefer these functions (macros) over the variadic
-
Creates an ordinary list term with length indicated by the
+ function name. Prefer these functions (macros) over the variadic
+
Create a list cell
Creates a list cell
Create an ordinary list containing the elements of array
Creates an ordinary list containing the elements of array
Returns an empty list if
Create an integer term from a
Creates an integer term from a
Make a copy of map
The
Makes a copy of map
If successful, this function sets
The
If map
The
If map
Returns
The
Make a copy of map
The
Makes a copy of map
If successful, this function sets
The
Allocate a binary of size
Return a pointer to the raw binary data and set
-
Allocates a binary of size
Returns a pointer to the raw binary data and sets
+
Make an empty map term.
Makes an empty map term.
+Make a pid term from
Makes a pid term from
Create a reference like
Creates 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
Creates an opaque handle to a memory-managed resource object
+ obtained by
Notice that the only defined behavior 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
Creates a binary term that is memory-managed by a resource object
+
Several binary terms can be managed by the same resource object. The + destructor is not called until the last binary is garbage collected. + This can be useful to return different parts of a larger binary + buffer.
+As with
Set
The
Sets
This function is only to be used on short lists, as a copy is + created of the list, which is not released until after the NIF + returns.
+The
Create a list containing the characters of the
- null-terminated string
Creates a list containing the characters of the
+
Create a list containing the characters of the string
Creates a list containing the characters of the string
Make a subbinary of binary
Makes a subbinary of binary
Create a tuple term of arity
Creates a tuple term of arity
Create a tuple term with length indicated by the
- function name. Prefer these functions (macros) over the variadic
-
Creates 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
Creates a tuple containing the elements of array
Create an integer term from an
Creates an integer term from an
Create an integer term from an unsigned 64-bit integer.
Creates an integer term from an unsigned 64-bit integer.
+Create an integer term from an
Creates an integer term from an
Returns a unique integer with the same properties as given by
Returns a unique integer with the same properties as specified by
+
-
See also:
-
See also
Create an iterator for the map
A map iterator is only useful during the lifetime of the environment
-
+ int enif_map_iterator_create(ErlNifEnv *env,
+ ERL_NIF_TERM map, ErlNifMapIterator *iter, ErlNifMapIteratorEntry
+ entry)
+ Create a map iterator.
+
+ Creates an iterator for the map map by initializing the
+ structure pointed to by iter . Argument entry determines
+ the start position of the iterator: ERL_NIF_MAP_ITERATOR_FIRST
+ or ERL_NIF_MAP_ITERATOR_LAST .
+ Returns true on success, or false if map is not a
+ map.
+ A map iterator is only useful during the lifetime of environment
+ env that the map belongs to. The iterator must be
+ destroyed by calling
+ enif_map_iterator_destroy :
+
ERL_NIF_TERM key, value;
ErlNifMapIterator iter;
enif_map_iterator_create(env, my_map, &iter, ERL_NIF_MAP_ITERATOR_FIRST);
@@ -1646,643 +2069,712 @@ 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.
-
+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
-
Destroys a map iterator created by
+
Get key and value terms at current map iterator position.
- On success set
Gets key and value terms at the current map iterator position.
+On success, sets
Return true if map iterator
Returns
Return true if map iterator
Returns
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).
+Increments map iterator to point to the next key-value entry.
+Returns
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).
+Decrements map iterator to point to the previous key-value entry.
+Returns
Arguments:
-
- Returns the current
-
Returns
See also:
-
Returns the current
+
Returns
See also
Same as
Same as
Same as
Same as
Same as
Same as
Same as
Same as
Same as
Same as
Retuns an
Returns an
This function is deprecated.
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
Creates or takes over a resource type identified by the string
+
The two flag values can be combined with bitwise OR. The resource
+ type name is local to the calling module. Argument
On success, the function returns a pointer to the resource type and
+
Notice 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:
Works as
Using a
Returns
See also
Return the pointer to the private data that was set by
Was previously named
Returns the pointer to the private data that was set by
+
Was previously named
Create an error exception with the term
See also:
Creates an error exception with the term
The return value from
See also
Change the size of a binary
Changes the size of a binary
Returns
Release a binary obtained from
Releases a binary obtained from
+
Remove a reference to resource object
Removes a reference to resource object
Same as
Same as
Same as
Same as
Same as
Same as
Same as
Same as
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 Schedules NIF The dirty NIF functionality described here is
+ experimental. You have to enable support for dirty
+ schedulers when building OTP to try out the functionality. Provides a name for the NIF that is scheduled for execution.
+ If it cannot be converted to an atom, Must be set to Can either be the originals passed into the calling NIF,
+ or can be values created by the calling NIF. The calling NIF must use the return value of
+ Be aware that
Initialize the pid variable
Initializes the pid variable
Returns
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
Sends a message to a process.
+Returns
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
Gets the byte size of resource object
Similar to
Similar to
Same as
Same as
Allocates a new binary with
Returns true on success or false if allocation failed.
-See also:
-
Allocates a new binary with
Returns
See also
Same as
Same as
Same as
Same as
Same as
Same as
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.
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:
-
Returns the current time offset between
+
Returns
See also
Same as
Same as
Same as
Same as
Same as
Same as
Same as
Same as