Send
Expr1 ! Expr2
Sends the value of Expr2 as a message to the process specified by Expr1. The value of Expr2 is also the return value of the expression.
Expr1 must evaluate to a pid, a registered name (atom) or a tuple {Name,Node}, where Name is an atom and Node a node name, also an atom.
* If Expr1 evaluates to a name, but this name is not registered, a badarg run-time error will occur.
* Sending a message to a pid never fails, even if the pid identifies a non-existing process.
* Distributed message sending, that is if Expr1 evaluates to a tuple {Name,Node} (or a pid located at another node), also never fails.
Receive
receive
Pattern1 [when GuardSeq1] ->
Body1;
...;
PatternN [when GuardSeqN] ->
BodyN
end
Receives messages sent to the process using the send operator (!). The patterns Pattern are sequentially matched against the first message in time order in the mailbox, then the second, and so on. If a match succeeds and the optional guard sequence GuardSeq is true, the corresponding Body is evaluated. The matching message is consumed, that is removed from the mailbox, while any other messages in the mailbox remain unchanged.
The return value of Body is the return value of the receive expression.
receive never fails. Execution is suspended, possibly indefinitely, until a message arrives that does match one of the patterns and with a true guard sequence.
Example:
wait_for_onhook() ->
receive
onhook ->
disconnect(),
idle();
{connect, B} ->
B ! {busy, self()},
wait_for_onhook()
end.
It is possible to augment the receive expression with a timeout:
receive
Pattern1 [when GuardSeq1] ->
Body1;
...;
PatternN [when GuardSeqN] ->
BodyN
after
ExprT ->
BodyT
end
ExprT should evaluate to an integer. The highest allowed value is 16#ffffffff, that is, the value must fit in 32 bits. receive..after works exactly as receive, except that if no matching message has arrived within ExprT milliseconds, then BodyT is evaluated instead and its return value becomes the return value of the receive..after expression.
Example:
wait_for_onhook() ->
receive
onhook ->
disconnect(),
idle();
{connect, B} ->
B ! {busy, self()},
wait_for_onhook()
after
60000 ->
disconnect(),
error()
end.
It is legal to use a receive..after expression with no branches:
receive
after
ExprT ->
BodyT
end
This construction will not consume any messages, only suspend execution in the process for ExprT milliseconds and can be used to implement simple timers.
Example:
timer() ->
spawn(m, timer, [self()]).
timer(Pid) ->
receive
after
5000 ->
Pid ! timeout
end.
There are two special cases for the timeout value ExprT:
infinity
The process should wait indefinitely for a matching message -- this is the same as not using a timeout. Can be useful for timeout values that are calculated at run-time.
0
If there is no matching message in the mailbox, the timeout will occur immediately.
Bit Syntax Expressions
<<>>
<<E1,...,En>>
Each element Ei specifies a segment of the bit string. Each element Ei is a value, followed by an optional size expression and an optional type specifier list.
Ei = Value |
Value:Size |
Value/TypeSpecifierList |
Value:Size/TypeSpecifierList
Used in a bit string construction, Value is an expression which should evaluate to an integer, float or bit string. If the expression is something else than a single
literal or variable, it should be enclosed in parenthesis.
Used in a bit string matching, Value must be a variable, or an integer, float or string.
Note that, for example, using a string literal as in <<"abc">> is syntactic sugar for <<$a,$b,$c>>.
Used in a bit string construction, Size is an expression which should evaluate to an integer.
Used in a bit string matching, Size must be an integer or a variable bound to an integer.
The value of Size specifies the size of the segment in units (see below). The default value depends on the type (see below). For integer it is 8, for float it is 64,
for binary and bitstring it is the whole binary or bit string. In matching, this default value is only valid for the very last element. All other bit string or binary
elements in the matching must have a size specification.
TypeSpecifierList is a list of type specifiers, in any order, separated by hyphens (-). Default values are used for any omitted type specifiers.
Type= integer | float | binary | bytes | bitstring | bits
The default is integer, bytes is a shorthand for binary and bits is a shorthand for bitstring
Signedness= signed | unsigned
Only matters for matching and when the type is integer. The default is unsigned.
Endianness= big | little | native
Native-endian means that the endianness will be resolved at load time to be either big-endian or little-endian, depending on what is native for the CPU that the Erlang
machine is run on. Endianness only matters when the Type is either integer or float. The default is big.
Unit= unit:IntegerLiteral
The allowed range is 1..256. Defaults to 1 for integer, float and bitstring, and to 8 for binary.
The value of Size multiplied with the unit gives the number of bits. A segment of type binary must have a size that is evenly divisible by 8.
Note: When constructing binaries, if the size N of an integer segment is too small to contain the given integer, the most significant bits of the integer will be silently
discarded and only the N least significant bits will be put into the binary.
Examples:
1> Bin1 = <<1,17,42>>.
<<1,17,42>>
2> Bin2 = <<"abc">>.
<<97,98,99>>
3> Bin3 = <<1,17,42:16>>.
<<1,17,0,42>>
4> <<A,B,C:16>> = <<1,17,42:16>>.
<<1,17,0,42>>
5> C.
42
6> <<D:16,E,F>> = <<1,17,42:16>>.
<<1,17,0,42>>
7> D.
273
8> F.
42
9> <<G,H/binary>> = <<1,17,42:16>>.
<<1,17,0,42>>
10> H.
<<17,0,42>>
11> <<G,H/bitstring>> = <<1,17,42:12>>.
<<1,17,1,10:4>>
12> H.
<<17,1,10:4>>
Note that bit string patterns cannot be nested.