File 0532-Second-pass.patch of Package erlang
From 9911e0b3dbd6b9b8062e5f060135bbfbfc90f46a Mon Sep 17 00:00:00 2001
From: Bryan Paxton <bryan@starbelly.io>
Date: Mon, 12 Sep 2022 09:57:45 -0500
Subject: [PATCH 2/8] Second pass
---
system/doc/design_principles/statem.xml | 15 ++++++++-------
1 file changed, 8 insertions(+), 7 deletions(-)
diff --git a/system/doc/design_principles/statem.xml b/system/doc/design_principles/statem.xml
index 7a8d9cee46..6ba8c53e1b 100644
--- a/system/doc/design_principles/statem.xml
+++ b/system/doc/design_principles/statem.xml
@@ -1912,15 +1912,16 @@ do_unlock() ->
to implicitly postpone any events to the <c>locked</c> state.
</p>
<p>
- A receive should not be used from a <c>gen_statem</c>
+ A receive all should never be used from a <c>gen_statem</c>
behaviour (or from any <c>gen_*</c> behaviour),
as the receive statement is within the <c>gen_*</c> engine itself.
- Doing so without taking all cases into consideration could result
- in system messages being discarded leading to unexpected behaviour.
- Even if all cases are taken into consideration the recvieve would
- still block system messages from arriving in a timely manor or
- indefinitely if a timeout is not provided.
- It must be there because all
+ Using a receive with a catch all match may result in system messages
+ being discarded which in turn may lead to unexpected behaviour.
+ If a selective receive must be used then great care should be taken to
+ ensure messages only messages pertitnent to the operation are caught.
+ Likewise, long running operations may result in timeouts and the
+ deferment of system messages, which in turn can lead to undesirable behaviour;
+ thus a reasonable timeout for any blocking operation should be used.
<seeerl marker="stdlib:sys"><c>sys</c></seeerl>
compatible behaviours must respond to system messages and therefore
do that in their engine receive loop,
--
2.35.3