File 0275-Remove-talk-about-SMP-vs-non-SMP-emulator.... of Package erlang

Overview Repositories Revisions Requests Users Attributes Meta

File 0275-Remove-talk-about-SMP-vs-non-SMP-emulator.patch of Package erlang (Revision 25a45d7bc626f46beadf15c2e119481e)

Currently displaying revision 25a45d7bc626f46beadf15c2e119481e , Show latest

From 58f50cc74d59e6f8513950a2d42e79fe37275c26 Mon Sep 17 00:00:00 2001
From: Sverker Eriksson <sverker@erlang.org>
Date: Thu, 29 Apr 2021 23:09:41 +0200
Subject: [PATCH 1/2] Remove talk about SMP vs non-SMP emulator.

---
 erts/doc/src/crash_dump.xml                   |  3 +-
 erts/doc/src/driver_entry.xml                 |  3 +-
 erts/doc/src/erl_driver.xml                   | 63 +++++--------------
 erts/doc/src/erl_nif.xml                      | 31 ++-------
 erts/doc/src/erts_alloc.xml                   |  4 +-
 lib/stdlib/doc/src/ets.xml                    |  4 +-
 system/doc/efficiency_guide/commoncaveats.xml |  3 +-
 system/doc/efficiency_guide/processes.xml     | 20 +++---
 8 files changed, 32 insertions(+), 99 deletions(-)

diff --git a/erts/doc/src/crash_dump.xml b/erts/doc/src/crash_dump.xml
index f5eab1273a..388b737ab9 100644
--- a/erts/doc/src/crash_dump.xml
+++ b/erts/doc/src/crash_dump.xml
@@ -233,8 +233,7 @@ Slogan: &lt;reason&gt;</pre>
 <item>
 If empty, the scheduler was doing some work.
 If not empty, the scheduler is either in some state of sleep,
- or suspended. This entry is only present in an SMP-enabled
- emulator.
+ or suspended.
 </item>
 <tag>Scheduler Sleep Info Aux Work</tag>
 <item>
diff --git a/erts/doc/src/driver_entry.xml b/erts/doc/src/driver_entry.xml
index cb6548d3f0..b3855a179f 100644
--- a/erts/doc/src/driver_entry.xml
+++ b/erts/doc/src/driver_entry.xml
@@ -465,8 +465,7 @@ typedef struct erl_drv_entry {
 <item>
 The runtime system uses port-level locking on
 all ports executing this driver instead of driver-level
- locking when the driver is run in a runtime
- system with SMP support. For more information, see
+ locking. For more information, see
 <seecref marker="erl_driver#smp_support">
 <c>erl_driver</c></seecref>.
 </item>
diff --git a/erts/doc/src/erl_driver.xml b/erts/doc/src/erl_driver.xml
index febfc27c99..ee571eb749 100644
--- a/erts/doc/src/erl_driver.xml
+++ b/erts/doc/src/erl_driver.xml
@@ -112,9 +112,8 @@
 the port. (Although in the latest Erlang versions there is
 the binary syntax, which enables you to match on the beginning of
 a binary.)
- <marker id="smp_support"></marker>In the runtime system with
- SMP support, drivers are locked either on driver level
- or port level (driver instance level). By default
+ <marker id="smp_support"></marker>Drivers are locked either on
+ driver level or port level (driver instance level). By default
 driver level locking will be used, that is, only one emulator thread
 will execute code in the driver at a time. If port level locking
 is used, multiple emulator threads can execute code in the driver
@@ -139,18 +138,6 @@
 communication" is strongly discouraged.
 </note>
 
- Previously, in the runtime system without SMP support,
- specific driver callbacks were always called from the same
- thread. This is not the case in the runtime system
- with SMP support. Regardless of locking scheme used, calls
- to driver callbacks can be made from different threads. For example,
- two consecutive calls to exactly the same callback for exactly
- the same port can be made from two different threads. This
- is for most drivers not a problem, but it can be.
- Drivers that depend on all callbacks that are called in the
- same thread, must be rewritten before they are used
- in the runtime system with SMP support.
-
 <note>
 Regardless of locking scheme used, calls to driver
 callbacks can be made from different threads.
@@ -167,9 +154,7 @@
 
 <warning>
 Functions not explicitly documented as thread-safe are
- not thread safe. Also notice that some functions
- are only thread-safe when used in a runtime
- system with SMP support.
+ not thread safe.
 A function not explicitly documented as thread-safe can, at
 some point in time, have a thread-safe implementation in the
 runtime system. Such an implementation can however change to
@@ -287,19 +272,8 @@
 omitted it from the Erlang driver thread API. In the Erlang driver
 case, time-outs can and are to be handled with the timer functionality
 of the Erlang driver API.
- In order for the Erlang driver thread API to function, thread
- support must be enabled in the runtime system. An Erlang driver
- can check if thread support is enabled by use of
- <seecref marker="#driver_system_info">
- <c>driver_system_info</c></seecref>.
- Notice that some functions in the Erlang driver API are thread-safe
- only when the runtime system has SMP support, also this
- information can be retrieved through
- <seecref marker="#driver_system_info">
- <c>driver_system_info</c></seecref>.
- Also notice that many functions in the Erlang driver API are
- not thread-safe, regardless of whether SMP support is
- enabled or not. If a function is not documented as thread-safe, it
+ Notice that many functions in the Erlang driver API are
+ not thread-safe. If a function is not documented as thread-safe, it
 is not thread-safe.
 <note>
 When executing in an emulator thread, it is
@@ -1177,8 +1151,7 @@ r = driver_async(myPort, &myKey, myData, myFunc); ]]></code>
 <item>Called from <seemfa marker="erlang#port_call/3">
 <c>erlang:port_call/3</c></seemfa>.</item>
 </taglist>
- Notice that this function is not thread-safe, not
- even when the emulator with SMP support is used.
+ Notice that this function is not thread-safe.
 </desc>
 </func>
 
@@ -1217,8 +1190,7 @@ r = driver_async(myPort, &myKey, myData, myFunc); ]]></code>
 <desc>
 <marker id="driver_connected"></marker>
 Returns the port owner process.
- Notice that this function is not thread-safe, not
- even when the emulator with SMP support is used.
+ Notice that this function is not thread-safe.
 </desc>
 </func>
 
@@ -1495,8 +1467,7 @@ r = driver_async(myPort, &myKey, myData, myFunc); ]]></code>
 <c>string</c>. The atom is created and does not change, so the
 return value can be saved and reused, which is faster than
 looking up the atom several times.
- Notice that this function is not thread-safe, not
- even when the emulator with SMP support is used.
+ Notice that this function is not thread-safe.
 </desc>
 </func>
 
@@ -1511,8 +1482,7 @@ r = driver_async(myPort, &myKey, myData, myFunc); ]]></code>
 <c>erl_drv_output_term</c></seecref> and 
 <seecref marker="#erl_drv_send_term">
 <c>erl_drv_send_term</c></seecref>.
- Notice that this function is not thread-safe, not
- even when the emulator with SMP support is used.
+ Notice that this function is not thread-safe.
 </desc>
 </func>
 
@@ -1602,8 +1572,7 @@ r = driver_async(myPort, &myKey, myData, myFunc); ]]></code>
 Parameters <c>term</c> and <c>n</c> work as in
 <seecref marker="#erl_drv_output_term">
 <c>erl_drv_output_term</c></seecref>.
- Notice that this function is not thread-safe, not
- even when the emulator with SMP support is used.
+ Notice that this function is not thread-safe.
 </desc>
 </func>
 
@@ -1905,8 +1874,7 @@ r = driver_async(myPort, &myKey, myData, myFunc); ]]></code>
 value of <c>mode</c>.
 </note>
 <c>ERL_DRV_USE</c> specifies if we are using the event object or
- if we want to close it.
- On an emulator with SMP support, it is not safe to clear all events
+ if we want to close it. It is not safe to clear all events
 and then close the event object after <c>driver_select</c> has
 returned. Another thread can still be using the event object
 internally. To safely close an event object, call
@@ -1952,8 +1920,7 @@ r = driver_async(myPort, &myKey, myData, myFunc); ]]></code>
 Parameters <c>term</c> and <c>n</c> work as in
 <seecref marker="#erl_drv_output_term">
 <c>erl_drv_output_term</c></seecref>.
- This function is only thread-safe when the emulator with SMP
- support is used.
+ This function is thread-safe.
 </desc>
 </func>
 
@@ -2647,8 +2614,7 @@ erl_drv_output_term(driver_mk_port(drvport), spec, sizeof(spec) / sizeof(spec[0]
 The <c>ERL_DRV_UINT</c>, <c>ERL_DRV_BUF2BINARY</c>, and
 <c>ERL_DRV_EXT2TERM</c> term types were introduced in
 ERTS 5.6.
- This function is only thread-safe when the emulator with SMP
- support is used.
+ This function is thread-safe.
 </desc>
 </func>
 
@@ -2853,8 +2819,7 @@ erl_drv_output_term(driver_mk_port(drvport), spec, sizeof(spec) / sizeof(spec[0]
 Parameters <c>port</c>, <c>term</c>, and <c>n</c> work as in
 <seecref marker="#erl_drv_output_term">
 <c>erl_drv_output_term</c></seecref>.
- This function is only thread-safe when the emulator with SMP
- support is used.
+ This function is thread-safe.
 </desc>
 </func>
 
diff --git a/erts/doc/src/erl_nif.xml b/erts/doc/src/erl_nif.xml
index faaebffbf4..0b88daf2b3 100644
--- a/erts/doc/src/erl_nif.xml
+++ b/erts/doc/src/erl_nif.xml
@@ -496,17 +496,6 @@ int writeiovec(ErlNifEnv *env, ERL_NIF_TERM term, ERL_NIF_TERM *tail,
 </item>
 <tag><marker id="dirty_nifs"/>Dirty NIF</tag>
 <item>
- <note>
- Dirty NIF support is available only when the emulator is
-	 configured with dirty scheduler support. As of ERTS version
-		9.0, dirty scheduler support is enabled by default on the
-		runtime system with SMP support. The Erlang runtime without
-		SMP support does not support dirty schedulers even
-		when the dirty scheduler support is explicitly enabled. To
-		check at runtime for the presence of dirty scheduler threads,
-		code can use the <seecref marker="#enif_system_info">
- <c>enif_system_info()</c></seecref> API function.
- </note>
 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.
@@ -1301,9 +1290,7 @@ typedef struct {
 <item>already triggered</item>
 <item>just about to be triggered by a concurrent thread</item>
 </list>
- 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.
+ This function is thread-safe.
 </desc>
 </func>
 
@@ -1991,9 +1978,7 @@ enif_inspect_iovec(env, max_elements, term, &amp;tail, &amp;iovec);
 <fsummary>Determine if a local port is alive.</fsummary>
 <desc>
 Returns <c>true</c> if <c>port_id</c> is alive.
- 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.
+ This function is thread-safe.
 </desc>
 </func>
 
@@ -2003,9 +1988,7 @@ enif_inspect_iovec(env, max_elements, term, &amp;tail, &amp;iovec);
 <fsummary>Determine if a local process is alive.</fsummary>
 <desc>
 Returns <c>true</c> if <c>pid</c> is alive.
- 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.
+ This function is thread-safe.
 </desc>
 </func>
 
@@ -2738,9 +2721,7 @@ enif_map_iterator_destroy(env, &amp;iter);</code>
 provided, and &gt; 0 if the process is no longer alive or if
 	 <c>target_pid</c> is <seecref marker="#enif_set_pid_undefined">
 	 undefined</seecref>.
- 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.
+ This function is thread-safe.
 </desc>
 </func>
 
@@ -3424,9 +3405,7 @@ if (retval &amp; ERL_NIF_SELECT_STOP_CALLED) {
 If <c>msg_env</c> is set to <c>NULL</c>, the <c>msg</c> term is
 copied and the original term and its environment is still valid after
 the call.
- 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.
+ This function is thread-safe.
 <note>
 Passing <c>msg_env</c> as <c>NULL</c> is only supported as from
 ERTS 8.0 (Erlang/OTP 19).
diff --git a/erts/doc/src/erts_alloc.xml b/erts/doc/src/erts_alloc.xml
index 7d8a3ebd5e..cd98123c5c 100644
--- a/erts/doc/src/erts_alloc.xml
+++ b/erts/doc/src/erts_alloc.xml
@@ -718,9 +718,7 @@
 <tag><marker id="M_t"/><c><![CDATA[+M<S>t true|false]]></c></tag>
 <item>
 Multiple, thread-specific instances of the allocator.
- This option has only effect on the runtime system
- with SMP support. Default behavior on the runtime system with
- SMP support is <c>NoSchedulers+1</c> instances. Each scheduler
+ Default behavior is <c>NoSchedulers+1</c> instances. Each scheduler
 uses a lock-free instance of its own and other threads use
 a common instance.
 Before ERTS 5.9 it was possible to configure
diff --git a/lib/stdlib/doc/src/ets.xml b/lib/stdlib/doc/src/ets.xml
index f66257337b..8f3c5131af 100644
--- a/lib/stdlib/doc/src/ets.xml
+++ b/lib/stdlib/doc/src/ets.xml
@@ -1308,8 +1308,8 @@ ets:select(Table, MatchSpec),</code>
 <item>
 Performance tuning. Defaults to <c>false</c>. When set to
 <c>true</c>, the table is optimized for concurrent read
- operations. When this option is enabled on a runtime system with
- SMP support, read operations become much cheaper; especially on
+ operations. When this option is enabled read operations
+	 become much cheaper; especially on
 systems with multiple physical processors. However, switching
 between read and write operations becomes more expensive.
 You typically want to enable this option when concurrent read
diff --git a/system/doc/efficiency_guide/commoncaveats.xml b/system/doc/efficiency_guide/commoncaveats.xml
index 35dd23aa9b..a0ed5f5b0d 100644
--- a/system/doc/efficiency_guide/commoncaveats.xml
+++ b/system/doc/efficiency_guide/commoncaveats.xml
@@ -43,8 +43,7 @@
 <seeerl marker="stdlib:timer">timer</seeerl> module in STDLIB.
 The <c>timer</c> module uses a separate process to manage the timers.
 That process can easily become overloaded if many processes
- create and cancel timers frequently (especially when using the
- SMP emulator).
+ create and cancel timers frequently.
 
 The functions in the <c>timer</c> module that do not manage timers
 (such as <c>timer:tc/3</c> or <c>timer:sleep/1</c>), do not call the
diff --git a/system/doc/efficiency_guide/processes.xml b/system/doc/efficiency_guide/processes.xml
index 033e7f109e..cef50c19ea 100644
--- a/system/doc/efficiency_guide/processes.xml
+++ b/system/doc/efficiency_guide/processes.xml
@@ -36,13 +36,11 @@
 An Erlang process is lightweight compared to threads and
 processes in operating systems.
 
- A newly spawned Erlang process uses 309 words of memory
- in the non-SMP emulator without HiPE support. (SMP support
- and HiPE support both add to this size.) The size can
+ A newly spawned Erlang process uses 326 words of memory. The size can
 be found as follows:
 
 <pre>
-Erlang (BEAM) emulator version 5.6 [async-threads:0] [kernel-poll:false]
+Erlang/OTP 24 [erts-12.0] [64-bit] [smp:8:8] [ds:8:8:10] [async-threads:1] [jit]
 
 Eshell V5.6 (abort with ^G)
 1> <input>Fun = fun() -> receive after infinity -> ok end end.</input>
@@ -372,18 +370,14 @@ true
 <section>
 <title>SMP Emulator</title>
 
- The SMP emulator (introduced in R11B) takes advantage of a
- multi-core or multi-CPU computer by running several Erlang scheduler
- threads (typically, the same as the number of cores). Each scheduler
- thread schedules Erlang processes in the same way as the Erlang scheduler
- in the non-SMP emulator.
+ The emulator takes advantage of a multi-core or multi-CPU
+ computer by running several Erlang scheduler
+ threads (typically, the same as the number of cores).
 
- To gain performance by using the SMP emulator, your application
+ To gain performance from a multi-core computer, your application
 must have more than one runnable Erlang process most of the time.
 Otherwise, the Erlang emulator can still only run one Erlang process
- at the time, but you must still pay the overhead for locking. Although
- Erlang/OTP tries to reduce the locking overhead as much as possible,
- it will never become exactly zero.
+ at the time.
 
 Benchmarks that appear to be concurrent are often sequential.
 The estone benchmark, for example, is entirely sequential. So is
-- 
2.26.2

Places

File 0275-Remove-talk-about-SMP-vs-non-SMP-emulator.patch of Package erlang (Revision 25a45d7bc626f46beadf15c2e119481e)

Places