aboutsummaryrefslogtreecommitdiffstats
path: root/erts/doc/src/erl_driver.xml
diff options
context:
space:
mode:
Diffstat (limited to 'erts/doc/src/erl_driver.xml')
-rw-r--r--erts/doc/src/erl_driver.xml27
1 files changed, 11 insertions, 16 deletions
diff --git a/erts/doc/src/erl_driver.xml b/erts/doc/src/erl_driver.xml
index 836a58a676..5705100ab2 100644
--- a/erts/doc/src/erl_driver.xml
+++ b/erts/doc/src/erl_driver.xml
@@ -4,7 +4,7 @@
<cref>
<header>
<copyright>
- <year>2001</year><year>2016</year>
+ <year>2001</year><year>2017</year>
<holder>Ericsson AB. All Rights Reserved.</holder>
</copyright>
<legalnotice>
@@ -1103,8 +1103,7 @@ r = driver_async(myPort, &myKey, myData, myFunc); ]]></code>
<marker id="driver_binary_dec_refc"></marker>
<p>Decrements the reference count on <c>bin</c> and returns
the reference count reached after the decrement.</p>
- <p>This function is only thread-safe when the emulator with SMP
- support is used.</p>
+ <p>This function is thread-safe.</p>
<note>
<p>The reference count of driver binary is normally to be decremented
by calling <seealso marker="#driver_free_binary">
@@ -1124,8 +1123,7 @@ r = driver_async(myPort, &myKey, myData, myFunc); ]]></code>
<desc>
<marker id="driver_binary_get_refc"></marker>
<p>Returns the current reference count on <c>bin</c>.</p>
- <p>This function is only thread-safe when the emulator with SMP
- support is used.</p>
+ <p>This function is thread-safe.</p>
</desc>
</func>
@@ -1137,8 +1135,7 @@ r = driver_async(myPort, &myKey, myData, myFunc); ]]></code>
<marker id="driver_binary_inc_refc"></marker>
<p>Increments the reference count on <c>bin</c> and returns
the reference count reached after the increment.</p>
- <p>This function is only thread-safe when the emulator with SMP
- support is used.</p>
+ <p>This function is thread-safe.</p>
</desc>
</func>
@@ -1434,8 +1431,7 @@ r = driver_async(myPort, &myKey, myData, myFunc); ]]></code>
<seealso marker="#driver_alloc_binary">
<c>driver_alloc_binary</c></seealso>. As binaries
in Erlang are reference counted, the binary can still be around.</p>
- <p>This function is only thread-safe when the emulator with SMP
- support is used.</p>
+ <p>This function is thread-safe.</p>
</desc>
</func>
@@ -1872,8 +1868,7 @@ r = driver_async(myPort, &myKey, myData, myFunc); ]]></code>
<p>Resizes a driver binary, while keeping the data.</p>
<p>Returns the resized driver binary on success. Returns <c>NULL</c>
on failure (out of memory).</p>
- <p>This function is only thread-safe when the emulator with SMP
- support is used.</p>
+ <p>This function is thread-safe.</p>
</desc>
</func>
@@ -1916,9 +1911,9 @@ r = driver_async(myPort, &myKey, myData, myFunc); ]]></code>
returned. Another thread can still be using the event object
internally. To safely close an event object, call
<c>driver_select</c> with <c>ERL_DRV_USE</c> and <c>on==0</c>, which
- clears all events. Then call
- <seealso marker="driver_entry#stop_select">
- <c>stop_select</c></seealso> when it is safe to close the event
+ clears all events and then either calls
+ <seealso marker="driver_entry#stop_select"><c>stop_select</c></seealso>
+ or schedules it to be called when it is safe to close the event
object. <c>ERL_DRV_USE</c> is to be set together with the first event
for an event object. It is harmless to set <c>ERL_DRV_USE</c>
even if it already has been done. Clearing all events but keeping
@@ -2039,7 +2034,7 @@ r = driver_async(myPort, &myKey, myData, myFunc); ]]></code>
<fsummary>Set and get limits for busy port message queue.</fsummary>
<desc>
<marker id="erl_drv_busy_msgq_limits"></marker>
- <p>Sets and gets limits that will be used for controling the
+ <p>Sets and gets limits that will be used for controlling the
busy state of the port message queue.</p>
<p>The port message queue is set into a busy
state when the amount of command data queued on the
@@ -2112,7 +2107,7 @@ r = driver_async(myPort, &myKey, myData, myFunc); ]]></code>
It is used to identify the condition variable in planned
future debug functionality.</p>
<p>Returns <c>NULL</c> on failure. The driver
- creating the condition variable is responsibile for
+ creating the condition variable is responsible for
destroying it before the driver is unloaded.</p>
<p>This function is thread-safe.</p>
</desc>