aboutsummaryrefslogtreecommitdiffstats
path: root/erts/doc/src
diff options
context:
space:
mode:
Diffstat (limited to 'erts/doc/src')
-rw-r--r--erts/doc/src/erl.xml6
-rw-r--r--erts/doc/src/erlang.xml28
2 files changed, 17 insertions, 17 deletions
diff --git a/erts/doc/src/erl.xml b/erts/doc/src/erl.xml
index 63ab2532ab..ec4a0dee05 100644
--- a/erts/doc/src/erl.xml
+++ b/erts/doc/src/erl.xml
@@ -371,7 +371,7 @@
path, similar to <c><![CDATA[code:add_pathsa/1]]></c>. See
<seealso marker="kernel:code">code(3)</seealso>.
As an alternative to <c>-pa</c>, if several directories are
- to be prepended to the code and the directories have a
+ to be prepended to the code path and the directories have a
common parent directory, that parent directory could be
specified in the <c>ERL_LIBS</c> environment variable.
See <seealso marker="kernel:code">code(3)</seealso>.</p>
@@ -1184,7 +1184,7 @@
disables this feature, which also is the default.
</p>
<p>This feature has been introduced as a temporary workaround
- for lengthy executing native code, and native code that do not
+ for long-executing native code, and native code that does not
bump reductions properly in OTP. When these bugs have be fixed
the <c>+sfwi</c> flag will be removed.
</p>
@@ -1210,7 +1210,7 @@
balance scheduler utilization between schedulers. That is,
strive for equal scheduler utilization on all schedulers.
<br/>&nbsp;&nbsp;&nbsp;<c>+sub true</c> is only supported on
- systems where the runtime system detects and use a monotonically
+ systems where the runtime system detects and uses a monotonically
increasing high resolution clock. On other systems, the runtime
system will fail to start.
<br/>&nbsp;&nbsp;&nbsp;<c>+sub true</c> implies
diff --git a/erts/doc/src/erlang.xml b/erts/doc/src/erlang.xml
index df7af3ce6b..94f9cd3148 100644
--- a/erts/doc/src/erlang.xml
+++ b/erts/doc/src/erlang.xml
@@ -1001,15 +1001,15 @@
can be used instead of
<c>demonitor(<anno>MonitorRef</anno>)</c> if this cleanup is wanted.</p>
<note>
- <p>Before OTP R11B (<c>ERTS</c> 5.5), <c>demonitor/1</c>
- behaved asynchronous, that is, the monitor was active
- until the "demonitor signal" reached the monitored entity.
- This had an undesirable effect, as you could never know when
- you were guaranteed <em>not</em> to receive a <c>DOWN</c>
- message because of the monitor.</p>
- <p>The current behavior can be viewed as two combined operations:
- asynchronously send a "demonitor signal" to the monitored
- entity and ignore any future results of the monitor.</p>
+ <p>Prior to OTP release R11B (ERTS version 5.5) <c>demonitor/1</c>
+ behaved completely asynchronously, i.e., the monitor was active
+ until the "demonitor signal" reached the monitored entity. This
+ had one undesirable effect. You could never know when
+ you were guaranteed <em>not</em> to receive a <c>DOWN</c> message
+ due to the monitor.</p>
+ <p>Current behavior can be viewed as two combined operations:
+ asynchronously send a "demonitor signal" to the monitored entity
+ and ignore any future results of the monitor. </p>
</note>
<p>Failure: It is an error if <c><anno>MonitorRef</anno></c> refers to a
monitoring started by another process. Not all such cases are
@@ -7877,9 +7877,9 @@ timestamp() ->
Secs = ErlangSystemTime div 1000000 - MegaSecs*1000000,
MicroSecs = ErlangSystemTime rem 1000000,
{MegaSecs, Secs, MicroSecs}.</code>
- <p>The BIF uses a native implementation which does
- not build garbage on the heap and with slightly better
- performance.</p>
+ <p>It, however, uses a native implementation which does
+ not build garbage on the heap and with slightly better
+ performance.</p>
<note><p>This time is <em>not</em> a monotonically increasing time
in the general case. For more information, see the documentation of
@@ -8812,8 +8812,8 @@ timestamp() ->
true
end</code>
<note>
- <p>Before OTP R11B (<c>ERTS</c> 5.5) <c>unlink/1</c>
- behaved asynchronous, that is, the link was active
+ <p>Prior to OTP release R11B (ERTS version 5.5) <c>unlink/1</c>
+ behaved completely asynchronously, i.e., the link was active
until the "unlink signal" reached the linked entity. This
had an undesirable effect, as you could never know when
you were guaranteed <em>not</em> to be effected by the link.</p>