aboutsummaryrefslogtreecommitdiffstats
path: root/lib/hipe
diff options
context:
space:
mode:
authorRickard Green <[email protected]>2018-03-21 11:54:28 +0100
committerGitHub <[email protected]>2018-03-21 11:54:28 +0100
commitcf3cbf0871832cb0808293842e5ae726edfc12e1 (patch)
treecd67d38d40c3414275ec257a6685b86c949c621a /lib/hipe
parent2c5711efcdd48ab8a9b7cd9ae27c97b9c1f8c37e (diff)
parent4bc282d812cc2c49aa3e2d073e96c720f16aa270 (diff)
downloadotp-cf3cbf0871832cb0808293842e5ae726edfc12e1.tar.gz
otp-cf3cbf0871832cb0808293842e5ae726edfc12e1.tar.bz2
otp-cf3cbf0871832cb0808293842e5ae726edfc12e1.zip
Merge pull request #1740 from rickard-green/rickard/signals/OTP-14589
Implementation of true asynchronous signaling between processes
Diffstat (limited to 'lib/hipe')
-rw-r--r--lib/hipe/doc/src/hipe_app.xml35
1 files changed, 35 insertions, 0 deletions
diff --git a/lib/hipe/doc/src/hipe_app.xml b/lib/hipe/doc/src/hipe_app.xml
index aaeb06193d..fc42ecd97d 100644
--- a/lib/hipe/doc/src/hipe_app.xml
+++ b/lib/hipe/doc/src/hipe_app.xml
@@ -99,6 +99,41 @@
each mode.</p>
</item>
+ <tag>Optimization for <c>receive</c> with unique references</tag>
+ <item>
+ <p>
+ The BEAM compiler can do an optimization when a receive
+ statement is only waiting for messages containing a reference
+ created before the receive. All messages that existed in the
+ queue when the reference was created will be bypassed, as they
+ cannot possibly contain the reference. HiPE currently has an
+ optimization similar this, but it is not guaranteed to
+ bypass all messages. In the worst case scenario it, cannot
+ bypass any messages at all.
+ </p>
+ <p>
+ An example of this is when <c>gen_server:call()</c> waits for
+ the reply message.
+ </p>
+ </item>
+
+ </taglist>
+ </section>
+ <section>
+ <title>Stability Issues</title>
+ <taglist>
+ <tag>Not yielding in <c>receive</c> statements</tag>
+ <item>
+ <p>HiPE will not yield in <c>receive</c> statements where
+ appropriate. If a process have lots of signals in its signal
+ queue and execute a HiPE compiled <c>receive</c> statement,
+ the scheduler thread performing the execution may be stuck
+ in the <c>receive</c> statement for a very long time. This
+ can in turn cause various severe issues such as for example
+ prevent the runtime system from being able to release
+ memory.
+ </p>
+ </item>
</taglist>
</section>
<section>