From 7ec7e60aea883bbc7d09e7dd6b68061ee8c6b15b Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Bj=C3=B6rn=20Gustavsson?=
Currently,
If
1> Bin = <<1,2,3>>
2> binary_part(Bin,{0,2}).
@@ -773,9 +773,9 @@ false
turned off, nothing happens.
Once demonitor(MonitorRef) has returned it is
guaranteed that no {'DOWN', MonitorRef, _, _, _} message
- due to the monitor will be placed in the callers message queue
+ due to the monitor will be placed in the caller's message queue
in the future. A {'DOWN', MonitorRef, _, _, _} message
- might have been placed in the callers message queue prior to
+ might have been placed in the caller's message queue prior to
the call, though. Therefore, in most cases, it is advisable
to remove such a 'DOWN' message from the message queue
after monitoring has been stopped.
@@ -818,7 +818,7 @@ false
flush
-
Remove (one) {_, MonitorRef, _, _, _} message,
- if there is one, from the callers message queue after
+ if there is one, from the caller's message queue after
monitoring has been stopped.
Calling demonitor(MonitorRef, [flush])
is equivalent to the following, but more efficient:
@@ -847,7 +847,7 @@ false
The monitor was not found and could not be removed.
This probably because someone already has placed a
'DOWN' message corresponding to this monitor
- in the callers message queue.
+ in the caller's message queue.
@@ -7090,7 +7090,7 @@ true
Id has no effect on the caller in the future (unless
the link is setup again). If caller is trapping exits, an
{'EXIT', Id, _} message due to the link might have
- been placed in the callers message queue prior to the call,
+ been placed in the caller's message queue prior to the call,
though. Note, the {'EXIT', Id, _} message can be the
result of the link, but can also be the result of Id
calling exit/2 . Therefore, it may be
--
cgit v1.2.3