aboutsummaryrefslogtreecommitdiffstats
path: root/erts/doc
diff options
context:
space:
mode:
Diffstat (limited to 'erts/doc')
-rw-r--r--erts/doc/src/erl.xml9
-rw-r--r--erts/doc/src/erl_nif.xml75
-rw-r--r--erts/doc/src/erlang.xml10
-rw-r--r--erts/doc/src/erts_alloc.xml11
-rw-r--r--erts/doc/src/notes.xml2
-rw-r--r--erts/doc/src/ref_man.xml30
6 files changed, 100 insertions, 37 deletions
diff --git a/erts/doc/src/erl.xml b/erts/doc/src/erl.xml
index 133f160dc9..05a9895687 100644
--- a/erts/doc/src/erl.xml
+++ b/erts/doc/src/erl.xml
@@ -1552,15 +1552,6 @@
parameter determines. The lingering prevents repeated
deletions and insertions in the tables from occurring.</p>
</item>
- <tag><marker id="+ztma"/><c>+ztma true | false</c></tag>
- <item>
- <p>Enables or disables support for tuple module apply in
- the emulator. This is a transitional flag for running code
- that uses parameterized modules and was compiled under OTP 20
- or earlier. For future compatibility, the modules will need
- to be recompiled with the +tuple_calls compiler option.
- Defaults to false.</p>
- </item>
</taglist>
</item>
</taglist>
diff --git a/erts/doc/src/erl_nif.xml b/erts/doc/src/erl_nif.xml
index 5cbeddabd9..95b7188882 100644
--- a/erts/doc/src/erl_nif.xml
+++ b/erts/doc/src/erl_nif.xml
@@ -2217,6 +2217,18 @@ enif_inspect_iovec(env, max_elements, term, &amp;tail, &amp;iovec);
</func>
<func>
+ <name since="OTP @OTP-15362@"><ret>ERL_NIF_TERM</ret>
+ <nametext>enif_make_monitor_term(ErlNifEnv* env, const ErlNifMonitor* mon)</nametext></name>
+ <fsummary>Make monitor term from the given monitor identifier.</fsummary>
+ <desc>
+ <p>Creates a term identifying the given monitor received from
+ <seealso marker="#enif_monitor_process"><c>enif_monitor_process</c>
+ </seealso>.</p>
+ <p>This function is primarily intended for debugging purpose.</p>
+ </desc>
+ </func>
+
+ <func>
<name since="OTP R14B"><ret>unsigned char *</ret><nametext>enif_make_new_binary(ErlNifEnv*
env, size_t size, ERL_NIF_TERM* termp)</nametext></name>
<fsummary>Allocate and create a new binary term.</fsummary>
@@ -3056,12 +3068,18 @@ enif_map_iterator_destroy(env, &amp;iter);</code>
<p>Argument <c>mode</c> describes the type of events to wait for. It can be
<c>ERL_NIF_SELECT_READ</c>, <c>ERL_NIF_SELECT_WRITE</c> or a bitwise
OR combination to wait for both. It can also be <c>ERL_NIF_SELECT_STOP</c>
- which is described further below. When a read or write event is triggered,
+ or <c>ERL_NIF_SELECT_CANCEL</c> which are described further
+ below. When a read or write event is triggered,
a notification message like this is sent to the process identified by
<c>pid</c>:</p>
<code type="none">{select, Obj, Ref, ready_input | ready_output}</code>
<p><c>ready_input</c> or <c>ready_output</c> indicates if the event object
is ready for reading or writing.</p>
+ <note><p>For complete control over the message format use the newer functions
+ <seealso marker="#enif_select_read"><c>enif_select_read</c></seealso> or
+ <seealso marker="#enif_select_write"><c>enif_select_write</c></seealso>
+ introduced in erts-11.0 (OTP-22.0).</p>
+ </note>
<p>Argument <c>pid</c> may be <c>NULL</c> to indicate the calling process.</p>
<p>Argument <c>obj</c> is a resource object obtained from
<seealso marker="#enif_alloc_resource"><c>enif_alloc_resource</c></seealso>.
@@ -3077,13 +3095,21 @@ enif_map_iterator_destroy(env, &amp;iter);</code>
<p>The notifications are one-shot only. To receive further notifications of the same
type (read or write), repeated calls to <c>enif_select</c> must be made
after receiving each notification.</p>
+ <p><c>ERL_NIF_SELECT_CANCEL</c> can be used to cancel previously
+ selected events. It must be used in a bitwise OR combination with
+ <c>ERL_NIF_SELECT_READ</c> and/or <c>ERL_NIF_SELECT_WRITE</c> to
+ indicate which type of event to cancel. The return value will
+ tell if the event was actualy cancelled or if a notification may
+ already have been sent.</p>
<p>Use <c>ERL_NIF_SELECT_STOP</c> as <c>mode</c> in order to safely
close an event object that has been passed to <c>enif_select</c>. The
<seealso marker="#ErlNifResourceStop"><c>stop</c></seealso> callback
of the resource <c>obj</c> will be called when it is safe to close
the event object. This safe way of closing event objects must be used
- even if all notifications have been received and no further calls to
- <c>enif_select</c> have been made.</p>
+ even if all notifications have been received (or cancelled) and no
+ further calls to <c>enif_select</c> have been made.
+ <c>ERL_NIF_SELECT_STOP</c> will first cancel any selected events
+ before it calls or schedules the <c>stop</c> callback.</p>
<p>The first call to <c>enif_select</c> for a specific OS <c>event</c> will establish
a relation between the event object and the containing resource. All subsequent calls
for an <c>event</c> must pass its containing resource as argument
@@ -3105,7 +3131,15 @@ enif_map_iterator_destroy(env, &amp;iter);</code>
<item>The stop callback was called directly by <c>enif_select</c>.</item>
<tag><c>ERL_NIF_SELECT_STOP_SCHEDULED</c></tag>
<item>The stop callback was scheduled to run on some other thread
- or later by this thread.</item>
+ or later by this thread.</item>
+ <tag><c>ERL_NIF_SELECT_READ_CANCELLED</c></tag>
+ <item>A read event was cancelled by <c>ERL_NIF_SELECT_CANCEL</c> or
+ <c>ERL_NIF_SELECT_STOP</c> and is guaranteed not to generate a
+ <c>ready_input</c> notification message.</item>
+ <tag><c>ERL_NIF_SELECT_WRITE_CANCELLED</c></tag>
+ <item>A write event was cancelled by <c>ERL_NIF_SELECT_CANCEL</c> or
+ <c>ERL_NIF_SELECT_STOP</c> and is guaranteed not to generate a
+ <c>ready_output</c> notification message.</item>
</taglist>
<p>Returns a negative value if the call failed where the following bits can be set:</p>
<taglist>
@@ -3131,6 +3165,39 @@ if (retval &amp; ERL_NIF_SELECT_STOP_CALLED) {
}
</code>
</note>
+ <note><p>The mode flag <c>ERL_NIF_SELECT_CANCEL</c> and the return flags
+ <c>ERL_NIF_SELECT_READ_CANCELLED</c> and
+ <c>ERL_NIF_SELECT_WRITE_CANCELLED</c> were introduced in erts-11.0
+ (OTP-22.0).</p>
+ </note>
+ </desc>
+ </func>
+
+ <func>
+ <name since="OTP 22.0"><ret>int</ret>
+ <nametext>enif_select_read(ErlNifEnv* env, ErlNifEvent event, void* obj,
+ const ErlNifPid* pid, ERL_NIF_TERM msg, ErlNifEnv* msg_env)</nametext>
+ </name>
+ <name since="OTP 22.0"><ret>int</ret>
+ <nametext>enif_select_write(ErlNifEnv* env, ErlNifEvent event, void* obj,
+ const ErlNifPid* pid, ERL_NIF_TERM msg, ErlNifEnv* msg_env)</nametext>
+ </name>
+ <fsummary>Manage subscription on IO event.</fsummary>
+ <desc>
+ <p>These are variants of <seealso marker="#enif_select">enif_select</seealso>
+ where you can supply your own message term <c>msg</c> that will be sent to
+ the process instead of the predefined tuple <c>{select,_,_,_}.</c></p>
+ <p>Argument <c>msg_env</c> must either be <c>NULL</c> or the environment of
+ <c>msg</c> allocated with <seealso marker="#enif_alloc_env">
+ <c>enif_alloc_env</c></seealso>. If argument <c>msg_env</c> is
+ <c>NULL</c> the term <c>msg</c> will be copied, otherwise both
+ <c>msg</c> and <c>msg_env</c> will be invalidated by a successful call
+ to <c>enif_select_read</c> or <c>enif_select_write</c>.</p>
+ <p>Apart from the message format <c>enif_select_read</c> and
+ <c>enif_select_write</c> behaves exactly the same as <seealso
+ marker="#enif_select">enif_select</seealso> with argument <c>mode</c> as
+ either <c>ERL_NIF_SELECT_READ</c> or <c>ERL_NIF_SELECT_WRITE</c>. To
+ cancel or close events use <seealso marker="#enif_select">enif_select</seealso>.</p>
</desc>
</func>
diff --git a/erts/doc/src/erlang.xml b/erts/doc/src/erlang.xml
index 6932b18571..e78ded4ae1 100644
--- a/erts/doc/src/erlang.xml
+++ b/erts/doc/src/erlang.xml
@@ -1751,6 +1751,10 @@ true</pre>
<item>
<p><c>Pid</c> is the process identifier of the process
that originally created the fun.</p>
+ <p>It might point to the <c>init</c> process if the
+ <c>Fun</c> was statically allocated when module was
+ loaded (this optimisation is performed for local
+ functions that do not capture the enviornment).</p>
</item>
<tag><c>{index, Index}</c></tag>
<item>
@@ -5206,11 +5210,13 @@ RealSystem = system + MissedSystem</code>
changed or removed without prior notice.</p>
</item>
<tag><c>{current_function, {<anno>Module</anno>,
- <anno>Function</anno>, Arity}}</c></tag>
+ <anno>Function</anno>, Arity} | undefined}</c></tag>
<item>
<p><c><anno>Module</anno></c>, <c><anno>Function</anno></c>,
<c><anno>Arity</anno></c> is
- the current function call of the process.</p>
+ the current function call of the process. The value
+ <c>undefined</c> can be returned if the process is
+ currently executing native compiled code.</p>
</item>
<tag><c>{current_location, {<anno>Module</anno>,
<anno>Function</anno>, <anno>Arity</anno>,
diff --git a/erts/doc/src/erts_alloc.xml b/erts/doc/src/erts_alloc.xml
index a094217959..962bc9a244 100644
--- a/erts/doc/src/erts_alloc.xml
+++ b/erts/doc/src/erts_alloc.xml
@@ -487,11 +487,10 @@
utilization value used. Once a carrier is abandoned, no new
allocations are made in it. When an allocator instance gets an
increased multiblock carrier need, it first tries to fetch an
- abandoned carrier from an allocator instance of the same
- allocator type. If no abandoned carrier can be fetched, it
- creates a new empty carrier. When an abandoned carrier has been
- fetched, it will function as an ordinary carrier. This feature has
- special requirements on the
+ abandoned carrier from another allocator instance. If no abandoned
+ carrier can be fetched, it creates a new empty carrier. When an
+ abandoned carrier has been fetched, it will function as an ordinary
+ carrier. This feature has special requirements on the
<seealso marker="#M_as">allocation strategy</seealso> used. Only
the strategies <c>aoff</c>, <c>aoffcbf</c>, <c>aoffcaobf</c>,
<c>ageffcaoff</c>m, <c>ageffcbf</c> and <c>ageffcaobf</c>
@@ -584,7 +583,7 @@
carriers are decided in section
<seealso marker="#mseg_mbc_sizes">
The alloc_util Framework</seealso>. On
- 32-bit Unix style OS this limit cannot be set &gt; 128 MB.</p>
+ 32-bit Unix style OS this limit cannot be set &gt; 64 MB.</p>
</item>
<tag><marker id="M_mbcgs"/><c><![CDATA[+M<S>mbcgs <ratio>]]></c></tag>
<item>
diff --git a/erts/doc/src/notes.xml b/erts/doc/src/notes.xml
index 9ea1beb887..3473a12526 100644
--- a/erts/doc/src/notes.xml
+++ b/erts/doc/src/notes.xml
@@ -10991,7 +10991,7 @@
you use erlang:halt/2 with an integer first argument and
an option list containing {flush,false} as the second
argument. Note that now is flushing not dependant of the
- exit code, and you can not only flush async threads
+ exit code, and you cannot only flush async threads
operations which we deemed as a strange behaviour anyway.
</p>
<p>Also, erlang:halt/1,2 has gotten a new feature: If the
diff --git a/erts/doc/src/ref_man.xml b/erts/doc/src/ref_man.xml
index a78aaa449e..811d299f06 100644
--- a/erts/doc/src/ref_man.xml
+++ b/erts/doc/src/ref_man.xml
@@ -31,26 +31,26 @@
</header>
<description>
</description>
- <xi:include href="erl_prim_loader.xml"/>
- <xi:include href="erlang.xml"/>
- <xi:include href="init.xml"/>
- <xi:include href="persistent_term.xml"/>
- <xi:include href="zlib.xml"/>
+ <xi:include href="atomics.xml"/>
+ <xi:include href="counters.xml"/>
+ <xi:include href="driver_entry.xml"/>
<xi:include href="epmd.xml"/>
<xi:include href="erl.xml"/>
+ <xi:include href="erlang.xml"/>
<xi:include href="erlc.xml"/>
- <xi:include href="werl.xml"/>
- <xi:include href="escript.xml"/>
- <xi:include href="erlsrv.xml"/>
- <xi:include href="start_erl.xml"/>
- <xi:include href="run_erl.xml"/>
- <xi:include href="start.xml"/>
<xi:include href="erl_driver.xml"/>
- <xi:include href="driver_entry.xml"/>
- <xi:include href="erts_alloc.xml"/>
<xi:include href="erl_nif.xml"/>
+ <xi:include href="erl_prim_loader.xml"/>
+ <xi:include href="erlsrv.xml"/>
<xi:include href="erl_tracer.xml"/>
- <xi:include href="atomics.xml"/>
- <xi:include href="counters.xml"/>
+ <xi:include href="erts_alloc.xml"/>
+ <xi:include href="escript.xml"/>
+ <xi:include href="init.xml"/>
+ <xi:include href="persistent_term.xml"/>
+ <xi:include href="run_erl.xml"/>
+ <xi:include href="start.xml"/>
+ <xi:include href="start_erl.xml"/>
+ <xi:include href="werl.xml"/>
+ <xi:include href="zlib.xml"/>
</application>