Erlang on cnDenis的笔记

【Erlang】lists:all/2 和 lists:any/2 对于空列表运算结果是啥?

Mon, 12 Jan 2015 00:00:00 +0000

先说结果, 无论F是什么, 结果都是这样:

 lists:all(F, []) = true
 lists:any(F, []) = false

换成其它语言也一样.

lists:all(F, []) = true

从逻辑上, 假如 A 和 B 是两个列表, 那么:

all(F, A ++ B) = all(F, A) andalso all(F, B)

显然, 如果一个大列表全部都是true, 把大列表分割成两个子列表后, 每个子列表中所有元素也都是true.

Erlang中, A = A ++ [], 所以

all(F, A ++ []) = all(F, A) andalso all(F, [])

只有 all(F, []) = true 才能保证上式恒成立.

lists:any(F, []) = false

类似的,

any(F, A ++ B) = any(F, A) orelse all(F, B)

因此,

any(F, A ++ []) = any(F, A) orelse all(F, [])

只有当 all(F, []) = false 才可以保证上式恒成立.

参考:

http://stackoverflow.com/questions/11979683/why-python-built-in-all-function-returns-true-for-empty-iterables

【Erlang】Erlang虚拟机的内部时钟

Fri, 19 Sep 2014 00:00:00 +0000

Erlang虚拟机可视为一个小型操作系统, 有自己的一套时钟系统, 与系统时间并不是完全一致的.

Erlang虚拟机时钟使用的是 erlang:now() 获取, 系统时间使用 os:timestamp() 获取. 格式是一样的三元组: {百万秒, 秒, 微秒}.

Erlang内部时钟的特点

为什么Erlang需要实现自己的虚拟机时钟呢? 因为系统时钟有时是不可靠的, 可能会因为联网自动对时或是管理员调时钟而发生突变或往回走, Erlang虚拟机时钟就是为了避免这些问题而设计的, 它有以下几个特点:

单向: 永远不会往回走
时间间隔接近于真实: 如果在两个时间读取虚拟机时钟, 读数为T1和T2, 那么T1-T2的值接近于两个时间点的真实时间间隔.
自动修正: 如果Erlang发现虚拟机内部时钟与系统时钟读数不一致, 它会自动缓慢地修正内部时钟, 使内部时钟与系统时钟一致.

第二点是说: 如果两次读取系统时钟, 发现时间相差1小时, 不一定是真实时间过了一小时, 可能是时钟被拨快了1小时, 实际上只过了几秒但Erlang虚拟机时钟则可以保证, 读数相差1小时, 那么实际时间过了大约一小时, 误差不超过1%.

第三点的实现方法是, Erlang发现内部时间和系统时间差距"较大"的话, 会调节内部时钟走时速度来适应外部时钟. 比方说外部时钟突然快了1分钟, Erlang会用100分钟来"追赶"外部时钟, 这段时间内Erlang内部时钟走时会快1%.

Erlang的这套时钟修正机制虽然不是完美的, 但可以避免出现时间跳跃问题, 防止定时器过早或过晚触发.

Erlang内部时钟的应用

Erlang内部时钟在以下这个几地方使用:

erlang:now()
receive...after
timer模块
erlang:start_timer/3 和 erlang:send_after/3

这就是说, 如果你用send_after设置1小时后给某进程发消息, 想调系统时间让消息快点到是不可能的, 老老实实等1小时吧.

erlang:now() 的特点

单向
间隔真实
自动修正
唯一

前三点由Erlang的内部时钟机制保证, 不必多说. 最后一点是指, 即使在多进程下, 每次调用erlang:now()都会获得不同的值. 因此erlang:now()的返回值也可以拿来当唯一ID用, 不用担心重复.

不过这个机制也会造成在高频率(每秒大于1百万次)调用时, erlang:now()的返回值有偏差. 因为它的返回值精度为1微秒, 1微秒调用2次的话, 也要值这个微秒数加2, 显得走快了.

当系统时间走时正常, 而且调用频率不高时, erlang:now()显示的时间和系统时间是一致的.

关闭内部时钟自动修正

可以在启动erl的时候, 使用+c参数, 关闭内部时钟的自动修正. 这是一般用不上的功能.

erlang:now() vs os:timestamp()

os:timestamp()返回的是系统时钟, 调系统时间的时候就会立即改变. 这对于进行时间相关的逻辑的测试时是很有用的.

erlang:now()在单进程下稍快于os:timestamp(), 但多进程竞争调用会变慢, 可以参考我在stackoverflow上的提问.

参考: Erlang Run-Time System Application (ERTS) 第1.2节

【Erl代码片段】start_timer/3 发送的消息中的TimerRef的用途

Fri, 20 Jun 2014 00:00:00 +0000

Erlang中有两个很相似的延迟发送消息的函数, send_after/3 和 start_timer/3, 区别仅在于前者返回Msg, 后者返回{timeout, TimerRef, Msg}. 后者的这个 TimerRef 有什么用呢?

坚强2002的博客给出了例子:

来自代码erl5.8.2\lib\stdlib-1.17.2\src\gen_fsm.erl

%% Returns Ref, sends event {timeout,Ref,Msg} after Time
%% to the (then) current state.
start_timer(Time, Msg) ->
 erlang:start_timer(Time, self(), {'$gen_timer', Msg}).

%% Returns Ref, sends Event after Time to the (then) current state.
send_event_after(Time, Event) ->
 erlang:start_timer(Time, self(), {'$gen_event', Event}).

%% Returns the remaing time for the timer if Ref referred to
%% an active timer/send_event_after, false otherwise.
cancel_timer(Ref) ->
 case erlang:cancel_timer(Ref) of
 false ->
 receive {timeout, Ref, _} -> 0
 after 0 -> false
 end;
 RemainingTime ->
 RemainingTime
 end.

代码十分清楚, 在取消定时器后, 可以利用这个Ref把消息队列中未处理的消息也删掉.

类似的用法在demonitor/1也可以看到. 取消掉一个monitor, 可以使用类似的方法, 把消息列队中的未处理的'DOWN'消息删掉:

demonitor(MonitorRef),
receive
 {_, MonitorRef, _, _, _} ->
 true
after 0 ->
 true
end

但是这样的代码不用自己写, Erlang自带的 demonitor(MonitorRef, [flush]) 就等价于上面的代码.

为什么demonitor提供了flush参数, 而cancel_timer没有呢? 因为 monitor/2 产生的消息只能发给调用它进程, 而 start_timer 产生的消息可以发给任意进程. 由于Erlang只允许读取本进程的消息队列, 不能干涉别的进程, 所以 cancel_timer 就不提供 flush 参数, 避免误解.

不过, 类似的 unlink/1 却也没有相应的 flush 参数可以用, 要自己刷消息队列:

unlink(Id),
receive
 {'EXIT', Id, _} ->
 true
after 0 ->
 true
end

呵呵.

【Erl代码片段】简易的并行版lists:map/2

Mon, 16 Jun 2014 00:00:00 +0000

Joe在书上示范了一个并行化的lists:map:

pmap(F, L) ->
 S = self(),
 %% make_ref() returns a unique reference
 %% we'll match on this later
 Ref = erlang:make_ref(),
 Pids = map(fun(I) ->
 spawn(fun() -> do_f(S, Ref, F, I) end)
 end, L),

 %% gather the results
 gather(Pids, Ref).

do_f(Parent, Ref, F, I) ->
 Parent ! {self(), Ref, (catch F(I))}.

gather([Pid|T], Ref) ->
 receive
 {Pid, Ref, Ret} -> [Ret|gather(T, Ref)]
 end;
gather([], _) ->
 [].

其实里面的Ref是没什么必要的, Pid本身就是不重复的, 可以用列表解析改简短一点:

pmap(F, L) ->
 Parent = self(),
 [receive {Pid, Result} -> Result end
 || Pid <- [spawn(fun() -> Parent ! {self(), (catch F(X))} end) || X <- L]].

如果不在乎返回值的次序, 可以用霸爷的版本: http://blog.yufeng.info/archives/401, 不过他没有在F(X)前加catch, 下面的代码中加上了. 他在论坛中解释说不加 catch 是为了"fail fast"(链接), 不过这并不完全成立, 因为F(X)是在新建的进程中执行的, 而且没有link, 出错只会使调用者无限等待, 并不见得特别好.

upmap(F, L) ->
 Parent = self(),
 Ref = make_ref(),
 [receive {Ref, Result} -> Result end
 || _ <- [spawn(fun() -> Parent ! {Ref, (catch F(X)} end) || X <- L]].

Tsung里有一个限制产生进程数的版本: https://github.com/processone/tsung/blob/master/src/tsung/ts_utils.erl#L874 如下:

pmap(F, L, NProcs) ->
 pmap(F, L, NProcs,"").

pmap(F, L, NProcs, Res) when length(L) > NProcs->
 {Head, Tail} = lists:split(NProcs,L),
 Parent = self(),
 lists:foldl(fun(X, Acc) -> spawn(fun() -> Parent ! {self(), F(X), Acc} end), Acc+1 end, 0, Head),
 NewRes = wait_result(NProcs,[]),
 pmap(F,Tail, NProcs, Res ++ NewRes);

pmap(F, L, _NProcs, Acc) ->
 Acc ++ pmap(F,L).

wait_result(0, Res)->
 {_Ids, RealRes} = lists:unzip(lists:keysort(1, Res)),
 RealRes;
wait_result(Nprocs, Res)->
 receive
 {_Pid, Result, Id} ->
 NewRes = Res ++ [{Id, Result}],
 wait_result(Nprocs-1, NewRes)
 end.

这代码看起来并不怎么好, 子进程发送的 {self(), F(X), Acc} 中self()是没有用的, 底下的 wait_result/2 也没有对它进行匹配, 合理来说这地方应该是一个 Ref 才对. 而且代码中先是 Res ++ [{Id, Result}], 然后又做 keysort, 并不太必要.

其实用现成的 pmap/2 去实现就可以了.

pmap(F, L, NProcs) ->
 pmap(F, L, NProcs, []).

pmap(F, L, NProcs, Res) when length(L) > NProcs->
 {Head, Tail} = lists:split(NProcs,L),
 pmap(F, Tail, NProcs, [pmap(F, Head)|Res]);

pmap(F, L, _NProcs, Res) ->
 Res1 = [pmap(F, L)|Res],
 lists:append(lists:reverse(Res1)).

由于创建进程和消息往返都有开销, 选择性消息接收会有遍历消息队列的开销, 只有当F是一个耗时的操作, 这些并行化的map才会比较划算.

【Erlang】ETS的并发性能调节选项

Sun, 08 Jun 2014 00:00:00 +0000

ETS在创建表时, 有 write_concurrency 和 read_concurrency 这两个选项, 可以用以优化ETS的并发性能.

write_concurrency 默认设置是 false, 当表进行写操作时, 整个表会被锁起来, 直到写完为止. 把这个值设置为 true, 可以优化并发写性能, 表中的不同项可以同时进行读写, 代价是会消耗一些内存, 并且会降低并发读的性能. 但是对于 order_set 类型的表, 目前的Erlang版本下是不受这个选项影响的.

read_concurrency 默认设置也是 false, 当设置为 true, 并且Erlang运行在多核机器上且开启SMP支持时, 并发读的性能会提升. 代价是读写切换变得更慢.

这两个选项是不会对操作的原子性和独立性有影响的, 也就是说这两项设置只改变性能, 不影响逻辑.

显然, write_concurrency 适用于读少写多的表, read_concurrency 适用于读多写少的表, 以及读写交替少的表 (即读一大堆数据后再写一大堆, 读取操作较少被写入操作打断).

这两个选项是可以同时开启的, 但额外的内存消耗会更大.

测试一下, 分别对默认, 开启read_concurrency, 开启write_concurrency 这三种设置, 测试 insert, lookup, update_counter 三种操作

bench for default ets
ets:insert/2
Single Process: 5664151 call per sec, 8388608 times in 1481 ms
 1000 Process: 2448296 call per sec, 4096000 times in 1673 ms
ets:lookup/2
Single Process: 6096372 call per sec, 8388608 times in 1376 ms
 1000 Process: 9481481 call per sec, 16384000 times in 1728 ms
ets:update_counter/3
Single Process: 5821379 call per sec, 8388608 times in 1441 ms
 1000 Process: 105872 call per sec, 128000 times in 1209 ms

bench for read_concurrency ets
ets:insert/2
Single Process: 5418997 call per sec, 8388608 times in 1548 ms
 1000 Process: 2493000 call per sec, 4096000 times in 1643 ms
ets:lookup/2
Single Process: 4981358 call per sec, 8388608 times in 1684 ms
 1000 Process: 10944555 call per sec, 16384000 times in 1497 ms
ets:update_counter/3
Single Process: 5769331 call per sec, 8388608 times in 1454 ms
 1000 Process: 1935727 call per sec, 2048000 times in 1058 ms

bench for write_concurrency ets
ets:insert/2
Single Process: 4371343 call per sec, 8388608 times in 1919 ms
 1000 Process: 2617252 call per sec, 4096000 times in 1565 ms
ets:lookup/2
Single Process: 4507580 call per sec, 8388608 times in 1861 ms
 1000 Process: 8062992 call per sec, 8192000 times in 1016 ms
ets:update_counter/3
Single Process: 4412734 call per sec, 8388608 times in 1901 ms
 1000 Process: 1889298 call per sec, 2048000 times in 1084 ms

可以看出, 开启并发性能优化的选项, 对于多进程的update_counter的性能有很大帮助.

【Erlang】gen_server terminate的坑

Sat, 07 Jun 2014 00:00:00 +0000

gen_server进程结束时, 会调用terminate函数, 但这并不是在任何情况下都成立的.

当gen_server进程主动关闭时, 也就是在回调函数 handle_xxx 中返回 {stop...} 的时候, terminate 是必然被调用的.

当gen_server进程处于监控树中, 被其监控进程关闭时, 情况就不一样了. 只有在这个进程设置了捕获退出信号, 即 process_flag(trap_exit, true), 并且其开启选项中设置了关闭超时时间, 而不是 brutal_kill, terminate才会被执行.

换句话说, 不捕获退出信号的gen_server被其监控进程关闭时, 会直接死掉, 不执行terminate函数!

看一下 gen_server 的源代码关于消息处理的部分:

decode_msg(Msg, Parent, Name, State, Mod, Time, Debug, Hib) ->
 case Msg of
 {system, From, Req} ->
 sys:handle_system_msg(Req, From, Parent, ?MODULE, Debug,
 [Name, State, Mod, Time], Hib);
 {'EXIT', Parent, Reason} ->
 terminate(Reason, Name, Msg, Mod, State, Debug);
 _Msg when Debug =:= [] ->
 handle_msg(Msg, Parent, Name, State, Mod);
 _Msg ->
 Debug1 = sys:handle_debug(Debug, fun print_event/3,
 Name, {in, Msg}),
 handle_msg(Msg, Parent, Name, State, Mod, Debug1)
 end.

可以看出, 当它的父进程执行 erlang:exit(Pid, Reason) 时, 也就是给它发送 {'EXIT', Parent, Reason}, gen_server会调用 terminate 并结束自己. gen_server源代码中并没有设置 trap_exit, 也就是默认是不捕获退出信号的, 如果用户不自己设置, 进程一旦接收到 {'EXIT', Parent, Reason} 就会立即退出, 没有机会运行 terminate.

从这段代码也可以看出, 设置 trap_exit 后, 用户并不需要而且没办法在 handle_info 里处理来自监控树的父进程的退出信号, gen_server在这个消息在到达 handle_info 之前就已经处理了, 直接调用了 terminate.

因此, 要确保监控树中的gen_server在进程结束时执行 terminate, 需要设置 process_flag(trap_exit, true), 并且要在启动参数中, 设置足够长的结束等待时间.

参考:

9 Erlang pitfalls you should know about, 其中第7条讲的就是这个问题, 有试验代码.
Erlang OTP之terminate 深入分析, 庆亮写的分析, 也有试验代码. 其中对于 simple_one_for_one 的描述不尽正确, 在目前的R16B中, simple_one_for_one 的子进程信息是存在 #state.dynamics 中的, 只要处理时间足够, 关闭监控树是会正常关闭所有子进程的.

OTP监控树笔记

Thu, 05 Jun 2014 00:00:00 +0000

这是Learn You Some Erlang中的Building an Applications with Otp的笔记.

在文中, OTP被戏称为Onion Theory Platform, 监控树像洋葱一样, 一层又一层.

OTP的哲学是工人-监工, 工作进程做错事就让它死掉, 监督进程再开启新的工作进程来干活. 这样做有个让人觉得很麻烦的问题: 工作进程死掉了, 它的状态怎么办? 文中进行了讨论. 状态可以分成三类:

静态的状态. 这从配置文件读回来就可以, 没什么问题.
动态但可重新获取的状态. 就是那些可以利用初始状态计算而来的东西, 重新算就行了.
动态且不可重新获取的状态. 比如说用户的输入, 外部事件等等.

如果工作进程只有前两类状态, 用监工的方法很容易的处理, 死了重启, 恢复状态就可以了.

第三类的状态需要放到不允许出错的地方(error kernel), 其实就是用try…catch包起来.

作者示范了一个进程池的设计.

所谓进程池, 就是可以容纳一定数量的进程同时运行, 当同时运行的进程数达到限制时, 把工作放入队列进行排队, 等待有空位时再开始新的任务.

做这么一个进程池, 需要有一个服务进程来计数同时运行的工作进程数, 以及保存准备等待运行的队列.

那用这个服务进程来监控工作进程好不好呢? 可以, 但缺点是服务进程任务太重, 而且和现有的监督者进程功能重复.

一个比较好的方案是, 用一个监督进程worker_sup监视所有工作进程, 这个监督进程和进程池服务进程一起放到上一层的监督进程ppool_sup下, 如图:

如果让所有进程池都放在同一个ppool_sup下, 当一个进程池频繁出错的话, 这个ppool_sup会被关掉, 所有进程池都会被关掉, 这是很不好的事情. 所以要为每个进程池单独开一个监控进程. 变成这样:

底下的具体实现部分就不记了.

实现这么看起来并不太复杂的功能, 从顶层到worker, 总共四层, 不愧是洋葱理论平台.

【Erl代码片段】cowboy的一处大小写处理代码

Fri, 30 May 2014 00:00:00 +0000

在cowboy的库cowlib中的cow_inline.hrl文件看到一堆很长的宏:

-define(INLINE_LOWERCASE(Function, Rest, Acc),
 $A -> Function(Rest, << Acc/binary, $a >>);
 $B -> Function(Rest, << Acc/binary, $b >>);
 $C -> Function(Rest, << Acc/binary, $c >>);
 $D -> Function(Rest, << Acc/binary, $d >>);
 $E -> Function(Rest, << Acc/binary, $e >>);
 $F -> Function(Rest, << Acc/binary, $f >>);
 $G -> Function(Rest, << Acc/binary, $g >>);
 $H -> Function(Rest, << Acc/binary, $h >>);
 $I -> Function(Rest, << Acc/binary, $i >>);
 $J -> Function(Rest, << Acc/binary, $j >>);
 $K -> Function(Rest, << Acc/binary, $k >>);
 $L -> Function(Rest, << Acc/binary, $l >>);
 $M -> Function(Rest, << Acc/binary, $m >>);
 $N -> Function(Rest, << Acc/binary, $n >>);
 $O -> Function(Rest, << Acc/binary, $o >>);
 $P -> Function(Rest, << Acc/binary, $p >>);
 $Q -> Function(Rest, << Acc/binary, $q >>);
 $R -> Function(Rest, << Acc/binary, $r >>);
 $S -> Function(Rest, << Acc/binary, $s >>);
 $T -> Function(Rest, << Acc/binary, $t >>);
 $U -> Function(Rest, << Acc/binary, $u >>);
 $V -> Function(Rest, << Acc/binary, $v >>);
 $W -> Function(Rest, << Acc/binary, $w >>);
 $X -> Function(Rest, << Acc/binary, $x >>);
 $Y -> Function(Rest, << Acc/binary, $y >>);
 $Z -> Function(Rest, << Acc/binary, $z >>);
 C -> Function(Rest, << Acc/binary, C >>)
).

底下还有2参数,3参数…10参数的版本.

找到一个调用的地方看看: cowboy_protocol.erl

parse_hd_name(<< C, Rest/bits >>, S, M, P, Q, V, H, SoFar) ->
case C of
 $: -> parse_hd_before_value(Rest, S, M, P, Q, V, H, SoFar);
 $\s -> parse_hd_name_ws(Rest, S, M, P, Q, V, H, SoFar);
 $\t -> parse_hd_name_ws(Rest, S, M, P, Q, V, H, SoFar);
 ?INLINE_LOWERCASE(parse_hd_name, Rest, S, M, P, Q, V, H, SoFar)
end.

还是看不明白, 用c(cowboy_protocol, ['P'])查看展开的宏, 上面的代码变成了:

parse_hd_name(<<C,Rest/bits>>, S, M, P, Q, V, H, SoFar) ->
 case C of
 $: ->
 parse_hd_before_value(Rest, S, M, P, Q, V, H, SoFar);
 $  ->
 parse_hd_name_ws(Rest, S, M, P, Q, V, H, SoFar);
 $\t ->
 parse_hd_name_ws(Rest, S, M, P, Q, V, H, SoFar);
 $A ->
 parse_hd_name(Rest, S, M, P, Q, V, H, <<SoFar/binary,$a>>);
 $B ->
 parse_hd_name(Rest, S, M, P, Q, V, H, <<SoFar/binary,$b>>);
 $C ->
 parse_hd_name(Rest, S, M, P, Q, V, H, <<SoFar/binary,$c>>);
 $D ->
 parse_hd_name(Rest, S, M, P, Q, V, H, <<SoFar/binary,$d>>);
 $E ->
 parse_hd_name(Rest, S, M, P, Q, V, H, <<SoFar/binary,$e>>);
 $F ->
 parse_hd_name(Rest, S, M, P, Q, V, H, <<SoFar/binary,$f>>);
 $G ->
 parse_hd_name(Rest, S, M, P, Q, V, H, <<SoFar/binary,$g>>);
 $H ->
 parse_hd_name(Rest, S, M, P, Q, V, H, <<SoFar/binary,$h>>);
 $I ->
 parse_hd_name(Rest, S, M, P, Q, V, H, <<SoFar/binary,$i>>);
 $J ->
 parse_hd_name(Rest, S, M, P, Q, V, H, <<SoFar/binary,$j>>);
 $K ->
 parse_hd_name(Rest, S, M, P, Q, V, H, <<SoFar/binary,$k>>);
 $L ->
 parse_hd_name(Rest, S, M, P, Q, V, H, <<SoFar/binary,$l>>);
 $M ->
 parse_hd_name(Rest, S, M, P, Q, V, H, <<SoFar/binary,$m>>);
 $N ->
 parse_hd_name(Rest, S, M, P, Q, V, H, <<SoFar/binary,$n>>);
 $O ->
 parse_hd_name(Rest, S, M, P, Q, V, H, <<SoFar/binary,$o>>);
 $P ->
 parse_hd_name(Rest, S, M, P, Q, V, H, <<SoFar/binary,$p>>);
 $Q ->
 parse_hd_name(Rest, S, M, P, Q, V, H, <<SoFar/binary,$q>>);
 $R ->
 parse_hd_name(Rest, S, M, P, Q, V, H, <<SoFar/binary,$r>>);
 $S ->
 parse_hd_name(Rest, S, M, P, Q, V, H, <<SoFar/binary,$s>>);
 $T ->
 parse_hd_name(Rest, S, M, P, Q, V, H, <<SoFar/binary,$t>>);
 $U ->
 parse_hd_name(Rest, S, M, P, Q, V, H, <<SoFar/binary,$u>>);
 $V ->
 parse_hd_name(Rest, S, M, P, Q, V, H, <<SoFar/binary,$v>>);
 $W ->
 parse_hd_name(Rest, S, M, P, Q, V, H, <<SoFar/binary,$w>>);
 $X ->
 parse_hd_name(Rest, S, M, P, Q, V, H, <<SoFar/binary,$x>>);
 $Y ->
 parse_hd_name(Rest, S, M, P, Q, V, H, <<SoFar/binary,$y>>);
 $Z ->
 parse_hd_name(Rest, S, M, P, Q, V, H, <<SoFar/binary,$z>>);
 C ->
 parse_hd_name(Rest, S, M, P, Q, V, H, <<SoFar/binary,C>>)
 end.

嗯, 这样就明白多了, 就是进行程序的逻辑处理同时, 把大写字母转换成小写.

测试一下这种写法的效率, 把一个大写的二进制串转成小写. Erlang没有原生的对二进制串做大小写转换的方法, 所以要先转列表, 转小写后再转回来.

%% 先转列表
lower_by_list(B) ->
 list_to_binary(string:to_lower(binary_to_list(B))).

%% inline的方法
lower_by_inline(B) ->
 lower_by_inline(B, <<>>).
lower_by_inline(<<C, R/bits>>, Acc) ->
 case C of
 ?INLINE_LOWERCASE(lower_by_inline, R, Acc)
 end;
lower_by_inline(<<>>, Acc) ->
 Acc.

对于1K字节的大写二进制串, 运行结果如下:

len: 1024
bench:lower_by_list/1
Single Process: 29925 call per sec, 32768 times in 1095 ms

bench:lower_by_inline/1
Single Process: 25090 call per sec, 32768 times in 1306 ms

如果单是做大小写转换, 这么做并不比先转列表再转回来快, 不过是可以省一点内存.

想起Erlang文档里的一句话: Do not guess about performance 出自这里. 这里用了相当复杂的方法完成了一个简单的工作, 或许是针对项目需求极度优化的结果, 如果不顾场合照搬, 那就是给自己添麻烦了.

【Erl代码片段】更快的proplists:get_value/3

Fri, 30 May 2014 00:00:00 +0000

在cowboy的cowboy_protocol.erl 文件中看到如这样一下函数:

%% Faster alternative to proplists:get_value/3.
get_value(Key, Opts, Default) ->
 case lists:keyfind(Key, 1, Opts) of
 {_, Value} -> Value;
 _ -> Default
 end.

做了一下测试, 考虑到proplist一般都不长, 用一个10个元素的列表进行测试, 结果这个函数比 proplists:get_value/3 快5倍, 对于更长的列表差别更大.

bench:get_value/3
Single Process: 13035909 call per sec, 16777216 times in 1287 ms

proplists:get_value/3
Single Process: 2273335 call per sec, 4194304 times in 1845 ms

速度差别原因主要是, keyfind 是BIF, 用C实现的, 而 proplists:get_value/3 是erlang实现的, 另外 proplists:get_value/3 把 atom 当作 {atom, true} 处理, 逻辑比 keyfind 复杂一些

这里另外一个测试和讨论: http://www.ostinelli.net/erlang-listskeyfind-or-proplistsget_value/,

Erlang数据项的size

Wed, 07 May 2014 00:00:00 +0000

Erlang中数据项(Erlang Term)的所占据的空间大小可以用各种size来获取.

其中对于所有数据项都通用的有: erlang:external_size/1, erts_debug:size/1, erts_debug:flat_size/1
适用于二进制串有: erlang:size/1, erlang:byte_size/1, erlang:bit_size/1
适用于元组的有: erlang:size/1, erlang:tuple_size/1

`erlang:external_size/1`

erlang:external_size/1 用来获取erlang数据项的外部格式(External Term Format)最大大小. 所谓外部格式, 就是用term_to_binary/1 打包形成的格式, 如果要把数据项从一台节点发到另一个节点, 或是持久化装到数据库中, 就需要打包成外部格式. 因此, 这个函数计算的传输erlang数据项的IO开销, 可以用来计算网络带宽或磁盘空间的占用量. 文档上说如下关系始终成立:

> Size1 = byte_size(term_to_binary(Term)),
> Size2 = erlang:external_size(Term),
> true = Size1 =< Size2.
true

也就是说用external_size/1函数算出来的空间需求可能会大于实际用term_to_binary/1 打包后的体积, 但这对于进行空间预算是没有问题的.

这个函数还有带多一个参数的版本erlang:external_size/2, 可以指打包的格式的版本, 目前版本之间只是对浮点数的处理有点不一样.

`erts_debug:flat_size/1` 和 `erts_debug:size/1`

erts_debug:size/1 和 erts_debug:flat_size/1 都是不在正式文档中的函数, 可以用来计算erlang数据项在内存中所需要空间. 各种数据项的空间占用可以在这里找到: http://www.erlang.org/doc/efficiency_guide/advanced.html#id68912. 这两个函数区别在于, 在具有共享内存的数据结构中, erts_debug:size/1只计算一次共享的数据大小, 而erts_debug:flat_size/1则会重复计算.

这是erlang源代码中的例子:

%% size(Term)
%% Returns the size of Term in actual heap words. Shared subterms are
%% counted once. Example: If A = [a,b], B =[A,A] then size(B) returns 8,
%% while flat_size(B) returns 12.

文档中有另外一个例子: http://www.erlang.org/doc/efficiency_guide/processes.html

总的来说, erts_debug:size/1是erlang数据项在内存中所占用的空间大小, erts_debug:flat_size/1是同一节点内, 跨进程移动数据项(包括ETS操作)所需要拷贝的数据大小.

`erlang:tuple_size/1`

作为自动导入的BIF, 一般不用写模块名erlang:. 这个函数功能很简单, 计算元组所包含的元素个数, 对于元组T来说, size(T) 就等于tuple_size(T), 后者指明了数据类型, 运行时微微快一点.

`erlang:byte_size/1` 和 `erlang:bit_size/1`

这两个也是自动导入, 一般不用写模块名. 它们是用来计算二进制串(binary)或是比特串(bitstring)所占的空间的. 对于二进制串B来说, size(B) 等于 byte_size(B).

Erlang中IPv4地址与整数的转换

Tue, 29 Oct 2013 00:00:00 +0000

IPv4地址通常表示为 A.B.C.D, 其中A-D都是0-255之间的整数, 总长为32位, 因此, 可以使用单一个32位无符号整数表示一个IP地址.

Erlang 中可以使用以下方式进行转换:

ip_to_int({A,B,C,D}) ->
 << Int:32 >> = <<A:8, B:8, C:8, D:8>>,
 Int.

int_to_ip(Int) ->
 <<A:8, B:8, C:8, D:8>> = << Int:32 >>,
 {A,B,C,D}.

上面两个函数没考虑溢出的问题, 溢出的部分会被截断, 比如说 A 输入 257 会被视为 1.

用二进制语法进行这种转换实在是优美, 比乘啊除啊好看多了.

Erlang的大小比较

Thu, 24 Oct 2013 00:00:00 +0000

Erlang 里, 不只数字可以比较大小, 基本上所有变量都可以比较大小.

大小关系是:

数字 < 原子 < reference < 函数 < 端口 < pid < 元组 < 列表 < 二进制

也就是说, 数字总是比原子小, 原子总是比列表小…

也就是说, 即使 Val > 5 为 true, 也不能保证 Val 是个数字.

而且, 同一种非数字类型也有大小, 比如说

 a > b %% 假
 "b" > "aa" %% 真

想不明白这样比较大小有啥意义, 真是个坑啊.

update: 2014年6月8日

所有数据项都可以比较, 在进行lists:sort/2的时候就会很方便.

而且, 要保证 Val 是个数字, 更合理的应该是 is_number(Val), 而不是判断它的大小.

Erlang的静态代码检查

Thu, 01 Aug 2013 00:00:00 +0000

Dialyzer是Erlang的静态代码检查程序, 可以发现函数调用时的类型错误之类的问题, 以及被调用的函数不存在或未导出的问题. 最实用的是在上传代码到SVN后, 检查是否漏传模块. 因为漏传的话, 编译不会报错, 但运行时会出undef错误, 从SVN上检出一份全新的代码, 用Dialyzer查一下, 漏的马上可以发现.

Dialyzer用法很简单, 只有三步: 建立PLT文件, 编译代码, 运行检查.

建立PLT文件

PLT文件是Dialyzer所用的代码规则的记录, 或者说是索引. 一般把代码所用到的几个常用的Erlang系统库加到PLT文件中就好了.

开始使用Dialyzer之前请先确定Erlang已正确安装, dialyzer.exe在系统搜索路径中.

写Dialyzer模块的人用的是Linux, 所以这东西对Windows不是特别友好, 它的PLT文件默认存放在HOME目录下, 而Windows一般是没有这个环境变量的, 所以Dialyzer一运行就报错. 因此首先要设置HOME变量, 指定为一个目录, 用以存放PLT文件.

建立PLT文件的命令是

 dialyzer --build_plt --apps erts kernel stdlib mnesia

其实 --build_plt 参数表示建立PLT文件, --app 后面写上代码中引用到的内置库即可.

这个命令运行时间比较长, 可能达到十几分钟, 请去喝杯咖啡慢慢等.

如果发现已经建立的PLT文件中漏了某些库, 可以使用 --add_to_plt 添加.

 dialyzer --build_plt --apps eunit

其实一不用加太多, 最常用的就上面几个, 检查代码时如果发现漏了, 再用 --add_to_plt 加上即可.

编译代码

Dialyzer可以检查源代码erl文件, 也可以检查编译好的beam文件. 我推荐是检查beam文件, 速度比较快.

用Dialyzer检查beam文件要求在编译beam文件时加上debug_info参数, 这样生成出来的beam才能用于dialyzer检查.

运行检查

对于编译好的beam文件, 只需要进入beam所在目录, 运行

 dialyzer .

即可检查该目录下所有beam文件, 或是

 dialyzer 文件名

即可检查某一文件.

如果希望把结果写入一个文件中, 可以使用-o参数, 如:

 dialyzer . -o Result.txt

这样会把结果写入Result.txt中.

Erlang中的长度

Sat, 27 Apr 2013 00:00:00 +0000

值得吐槽的是居然连求长度这么基础的方法，Erlang都没有统一起来。分为len和size两大对立阵营：

len阵营

列表（字符串是列表的一种）的长度用length/1或string:len/1。别看后面那个打着string开头，对于不是字符串的列表也照用不误，从源代码看其实就是前一个的马甲。
queue模块是len阵营的，使用queue:len/1。

size阵营

二进制串的长度用size/1，或是用byte_size/1和bit_size/1也行，分别是比特长度和位长度，1byte = 8bit。
元组的长度也用size/1，等于其元素的个数。元组的比特长度和位长度不可用。
dict，sets，orddict，ordsets，array, gb_trees, gb_sets 这几个模块也是size阵营的，使用其各自模块下的size函数。
iolist 有BIF iolist_size/1可用.
ets比较特别，使用ets:info(Tab, size)来获取长度，Tab是表的id，或是已注册的表的名字。

另外，特立独行的“原子”没有长度。

更新(2013年9月13日)

其实Erlang对这两个方法的区分也是道理的, len是O(n)时是复杂度的函数 (是不是觉得这是另一种蛋疼), 而size是O(1)的. 换句话说就是数据长度越大, 取len的时间越长, 但取size用的时间却不受长度影响.

Erlang中的原子、字符串和二进制串

Fri, 26 Apr 2013 00:00:00 +0000

Erlang中的原子（Atom）, 字符串（String）和二进制串（Binary）是有点容易让人糊涂的东西, 这里归纳一下它们之间的区别与联系。

原子

原子是由小写字母开头, 后接大小写字母及数字及下划线的, 比方说abc, cDE, ff89, 或是由单引号’‘括起来的任意字符, 比方说’EXIT’, ‘!@#@!$sdaf’。用过其他语言的话, 会觉得Erlang中没括起来的原子长得像变量, 括起来的长得像字符串, 但其实都不是, 这点要特别注意。Erlang中的变量是以大写字母开头的, 字符串是用双引号括起来的。

原子在Erlang中应用非常广, 模块名、函数名、记录名都是原子, 所以如果你够蛋疼的话, 可以用’!#@$#y3fdsa1’（包括两边的单引号）当做函数名。

原子顾名思义是“不可分割”的东西, 原子无论长短, 在内存中占用的空间都是一样的, 然而, 原子的名字也不是毫无意义的, 可以利用atom_to_binary把原子名转成二进制串, 也可以用atom_to_list把原子名转成字符串。反过来也可以, 有binary_to_atom和list_to_atom可以用。

Erlang中是没有原生的原子连接方法, 真想要相连的话, 先要转成二进制串或是字符串.

字符串

Erlang中字符串是使用双引号括起来的一串字符, 例如"string", “123"等等。双引号其实只是一个简写形式, 其实并没有把“字符串”当作一种独立的数据类型, 而是用正整数的列表（List）作为字符串使用, 跟C里面的做法相似。以下三行是等价的：

 "hello"
 [$h, $e, $l, $l, $o]
 [104,101,108,108,111]

因此字符串转换成原子及二进制串的的函数名为list_to_atom和list_to_binary。

Erlang中的有专门处理字符串的模块, string, 可以用以进行大小写变换、截断、对齐、连接、分割、子字符串等等常用操作。由于字符串实质上是列表, 因此lists 模块里的方法也全都适用于字符串。

字符串是列表, 因此可以使用列表的连接运算符++进行连接。二进制串是不可以用++的。虽然拿 字符串++二进制串 在语法上是允许的, 但得到的结果是一个 “非正规列表” （也有人翻译成 “非严格列表” ）, 是不推荐这么做的。

二进制串

二进制串是Erlang的一项特色, 使用在代码中使用<< >>括起来（看起来有点像中文的书名号, 其实是两个小于号和两个大于号）。括起来的内容可以用数字表示, 或是用对应的字符串表示, 如下：

 << 97, 98, 99 >>
 << "abc" >>

这两者含义是相同的。但要注意的是, 和列表[ ]或元组{ }不一样的是, 双引号只是一种简记方式, 并不是说把一个字符串放到<< >>里就会变成二进制串的, 比方说以下的写法都是不对的。

 << [97, 98, 99] >>
 A = "abc", << A >>

正确的做法是:

 A = "abc",
 A1 = list_to_binary(A),
 << A1/binary >>,
 %% 或者
 << (list_to_binary(A))/binary >>,

记住, 在二进制串中使用函数的话, 必须要用括号括起来.

<< >>里可以接受数字和二进制串, 利用所谓的比特语法构造二进制串或进行模式匹配。格式为 变量:大小/类型, 例如:

 X:4/little-signed-integer-unit:8 %% 把X存为有符号小端整数, 大小为 4*8 bit
 A:32/integer %% 把A存储为32位整数
 B:15/binary %% 要求B是长于或等于15字节的二进制串, 截取B的前15字节

变量:大小/类型 的格式中, 大小和类型是可以省略的, 因此可以有:

变量:大小
变量/类型
变量

当进行省略时, 会使用默认值:

缺省的类型是整数 ( 手册上的例子是有点问题的, «3.14»这样的写法在 Erlang 16B 版上是非法的).
缺省的大小与类型有关:

整数是8位, 溢出部分被截掉: 例如<< 257 >>等价于<< 257:8 >>, 值等于<< 1 >>

浮点数是64位

二进制串是整个串的长度: 例如<< A/binary >>会把整个A都存起来.
对于整数, 缺省是无符号的.
对于整数, 缺省是大端的(big-endian).
可以使用 -unit:长度 的方式来指定单位长度, 缺省的单位长度与类型有关.

整数(integer)/浮点数(float)/字节串(bitstring) 的缺省长度是1.

而binary类型缺省长度是8.

二进制的连接直接在<< >>中使用逗号放一起就可以了, 例如

 << A/binary, B/binary >>,

 << 1234:32, "String", "中文也可以", "引号的后面不能加/binary", <<"但是二进制串中括另一个二进制串要指定格式">>/binary >>

其它的二进制语法, 例如二进制中的模式匹配/二进制解析, 等等, 就不在这里讲了.

参考:

官方手册

gen_server笔记

Wed, 24 Apr 2013 00:00:00 +0000

gen_server是erlang的OTP框架中最常用的“行为模式”了吧，至少几本erlang教材都是首先介绍这个。

~~这东西用来做什么的呢？或者说，为什么要用这东西呢？由于我接触这东西不过几天，理解尚非常粗浅，就我看来，用gen_server有以下几个好处：~~

面向对像，封装数据与方法。gen_server内部需要维护一个状态State，并提供各种函数给别人调用，就类似于其他语言中的“类”一样，把数据和方法封装在一起，防止数据被非法改动。

简化调用，屏蔽通讯。erlang中如果要自己实现远程过程调用（RPC）的话，需要自己定义消息格式，自己编写封装与解包的代码，还要处理各种异常问题，这些gen_server 都帮我们做好了，只需要像平常使用函数一样直接调就用行了，省时省力还不出错。

热代码替换等高级功能。热代码替换是erlang大力宣传的一项特色功能，不停机维护在生产上是非常美妙的事。不过这是高级功能，初学暂时用不上，书上也没多讲。

gen_server模板

gen_server是可以使用模板来写的，如下：

 -module().

 -behaviour(gen_server).

 %% API
 -export([]).

 %% gen_server callbacks
 -export([init/1, handle_call/3, handle_cast/2, handle_info/2,
 terminate/2, code_change/3]).

 -define(SERVER,?MODULE).

 start_link() ->
 gen_server:start_link({local, ?SERVER}, ?MODULE, [], []).

 init([]) ->
 {ok, State}.

 handle_call(_Request, _From, State) ->
 {reply, Reply, State}.

 handle_cast(_Msg, State) ->
 {noreply, State}.

 handle_info(_Info, State) ->
 {noreply, State}.

 terminate(_Reason, _State) ->
 ok.

 code_change(_OldVsn, State, _Extra) ->
 {ok, State}.

含义如下：

-module 是模块名，就是文件名。

-behaviour 是指定“行为模式”，在这里就是gen_server，作用在于用于检查这个模块是否实现gen_server的所有接口。也就是 init/1, handle_call/3, handle_cast/2, handle_info/2, terminate/2, code_change/3这六个函数。缺少的话编译器就会报错。

-export 有两个，第一个里面写的是API，也就是供别人调用的接口，第二个是gen_server 的接口，就是上面说的那六个。其实要写到同一个export里也可以，不过分开写比较清楚。

接下来就是各API函数，一般来说就是封装、调用各用回调函数的包装函数。

再往后就是六个回调函数的具体实现。回调函数是负责具体干活的。

大概可以做这么个比喻吧，如果整个模块是个昆虫，API是就头，gen_server就是身子，而回调函数是六条腿。你告诉头说要去哪里，腿就运动起来，整条虫子就跑起来了。身子是把各条腿粘起来，否则单独的腿只能在原地抽筋，哪都去不了。

启动服务器

用来启动服务器的有start/3,start/4,start_link/3,start_link/4这四个函数。使用这些start函数之后，就会产生一个新的进程，也就是一个gen_server服务器。这些 start函数的正常情况下返回值是{ok,Pid}，Pid就是这个新进程的进程号。带link与不带的区别在于是否跟父进程建立链接，换种说法是，新启动的进程死掉后，会不会通知启动他的进程（父进程）。

start函数可以四个参数(ServerName, Module, Args, Options)：

第一个参数ServerName是服务名，是可以省掉的。具有相同服务名的模块在一个节点中只能启动一次，重复启动会报错，为 {error, {already_started, Pid}}。具有服务名的服务进程可以使用服务名来调用，没有服务名的只能通过进程号pid来调用了。通常有名字的服务进程会使用模块名做为服务名，即上面模板中定义的宏-define(SERVER, ?MODULE)，然后在需要使用服务名的地方填入?SERVER.
第二个参数Module是模块名，一般而言API和回调函数是写在同一个文件里的，所以就用 ?MODULE，表示本模块的模块名。
第三个参数Args是回调函数init/1的参数，会原封不动地传给init/1。
第四个参数Options是一些选项，可以设置debug、超时等东西。

start是对应的回调函数是init/1，一般来说是进行服务器启动后的一些初始化的工作，并生成初始的状态State，正常返回是{ok, State}。这个State是贯穿整个服务器，并把所有六个回调函数联系起来的纽带。它的值最初由init/1生成，此后可以由三个handle函数修改，每次修改后又要放回返回值中，供下一个被调用的handle函数使用。如果init/1返回ignore或{stop, Reason}，则会中止服务器的启动。

有一点细节要注意的是，API函数和回调函数虽然习惯上是写在同一个文件中，但执行函数的进程却通常是不一样的。在上面的模板中，start_link/0中使用self()的话，显示的是调用者的进程号，而在init/1中使用self()的话，显示的是服务器的进程号。

使用服务器

三个handle开头的回调函数对应着三种不同的使用服务器的方式。如下：

gen_server:call ------------- handle_call/3
gen_server:cast ------------- handle_cast/2
用！向服务进程发消息------------- handle_info/2

call是有返回值的调用；cast是无返回值的调用，即通知；而直接向服务器进程发的消息则由handle_info处理。

call

call是有返回值的调用，也是所谓的同步调用，进程会在调用后一直等待直到回调函数返回为止。它的函数形式是 gen_server:call(ServerRef, Request, Timeout) -> Reply，

第一个参数ServerRef是被调用的服务器，如果是服务器名，或是服务器的pid。
第二个参数Request会直接传给回调函数handle_call
最后一个参数Timeout是超时，是可以省略的，默认值是5秒。

在多节点的情况下，还有机会使用到multi_call，用来向各节点上的同具有相同注册名的服务进程发起调用。（这个函数在文档上的表述有点让人难以理解，详见这里）

call是用来指挥回调函数handle_call/3干活的。具体形式为 handle_call(Request, From, State)。

第一个参数Request是由call传进来的，是写程序时关注和处理的重点。
第二个参数From是gen_server传进来的，是调用的来源，也就是哪个进程执行了call。 From的形式是{Pid, Ref}，Pid是来源进程号，而Ref是调用的标识，每一次调用都不一样，用以区别。有了Pid，在需要向来源进程发送消息时就可以使用，但由于call 是有返回值的，一般使用返回值传递数据就好。
第三个参数State是服务器的状态，这是由init或是其他的handle函数生成的，可以根据需要进行修改之后，再放回返回值中。

call对应的回调函数handle_call/3在正常情况下的返回值是{reply, Reply, NewState}， Reply会作为call的返回值传递回去，NewState则会作为服务器的状态。另外还可以使用{stop, Reasion, State}中止服务器运行，这比较少用。

使用call要小心的是，两个服务器进程不能互相call，不然会死锁。

cast

cast是没有返回值的调用，一般把它叫做通知。它是一个“异步”的调用，调用后会直接收到 ok，无需等待回调函数执行完毕。

它的形式是gen_server:cast(ServerRef, Request)。参数含义与call相同。由于不需要等待返回，所以没必要设置超时，没有第三个参数。

在多节点的情况下，可以用abcast，向各节点上的具有指定名字的服务进程发通知。（奇怪的是为啥为不叫multi_cast，明明长得跟multi_call很像的）

cast们对应的回调函数是handle_cast/2，具体为：handle_cast(Msg, State)。第一个参数是由cast传进去的，第二个是服务器状态，和call类似，不多说。

handel_cast/2的返回值通常是{noreply, NewState}，这可以用来改变服务器状态，或是{stop, Reason, NewState}，这会停止服务器。通常来说，停止服务器的命令用 cast来实现比较多。

原生消息

原生消息是指不通过call或cast，直接发往服务器进程的消息，有些书上译成“带外消息”。比方说网络套接字socket发来的消息、别的进程用!发过来的消息、跟服务器建立链接的进程死掉了，发来{'EXIT', Pid, Why}等等。一般写程序要尽量用API，不要直接用!向服务器进程发消息，但对于socket一类的依赖于消息的应用，就不得不处理原生消息了。

原生消息使用handle_info/2处理，具体为handle_info(Info, State)。其中Info是发过来的消息的内容。回复和handle_cast是一样的。

停止服务器

上面介绍的handle函数返回{stop,…}，就会使用回调函数terminate/2进行扫尾工作。典型的如关闭已打开的资源、文件、网络连接，打log做记录，通知别的进程“我要死啦”，或是“信春哥，满血复活”：利用传进来的状态State重新启动服务器。

最简单的就是啥都不干，返回ok就好了。

参考资料和资源：

gen_server的文档

OTP设计原则中gen_server的介绍

更新(2013年9月13日)

虽然笔记跟抄书没啥区别, 但抄一遍总会加强记忆的, 所以还是贴出来.

call 操作会阻塞, 而且有死锁的可能性, 用起来要小心.

初识Erlang，Hello World（4）

Sun, 24 Mar 2013 00:00:00 +0000

前几节的Hello world都是自言自语，今天试试对着别人说。首先是在本机上各个进程之间，然后是在网络上不同机器之间。

进程间的消息：单向接收

Erlang里可以很方便地创建进程，这种进程是超轻量级的，运行于erlang虚拟机内部的，而与操作系统的进程管理无关的（也就是说你在任务管理器中只会见到一个Erlang进程）， Erlang内的进程创建开销很小，创建一个进程所需的时间仅为微秒级，内存消耗也很少，一台机上运行数以千计的进程也没问题。

进程之间使用消息进行通讯。示例如下：

 hw15srv() ->
 receive
 {name, Name} ->
 io:format("Hello ~p ~n", [Name]),
 hw15srv()
 end.

 hw15() ->
 Pid = spawn(fun hw15srv/0),
 Pid ! {name, "alice"},
 Pid ! {name, "Bob"}.

hw15/0首先是使用spawn命令启动了一个hw15srv/0进程，。这个命令会返回所启动的进程的pid，也就是进程的标识符。然后使用!向它发送消息。

spawn命令有几种用法，对于上例，以下几种方式都可以

 spawn(fun hw15srv/0)
 spawn(fun() -> hw15srv() end)
 spawn(?MODULE, hw15srv, [])

要注意的是，第三种用法（也叫MFA法，即模块、函数、参数法）进行调用的话，这个被调用的函数（即示例中的hw15srv) 必须要export出来，即便是写在同一个文件中。

hw15srv/0的作用是接收其他进程给他发的消息，并显示出来。接收消息使用receive，格式有点象case，先是对收到的消息进行模式匹配，如果匹配的话，该项->后的语句。

发送消息的进程和接收消息的进程需要协调好消息的格式，这段程序中，消息是一个元组，元组的第一个元素是原子name，（一般习惯中erlang中的元组的第一个元素用一个原子作元组的命名），第二个元素是一个字符串。

hw15srv/0用的是所谓尾递归服务器的写法，语句段的最后一行写上递归函数名，象这样的服务器一定要符合尾递归的要求，不然的话运行一段时间服务器就会把内存塞爆。

进程间的消息：相互对话

上一段程序中，hw15srv/0是只收不发的，别人对它说什么，它都没有响应。如果需要有回应的话，可以这么写：

 hw16srv() ->
 receive
 {From, {name, Name}} ->
 io:format("Server receive: ~p ~n", [Name]),
 From ! {self(), {reply, "Welcome, " ++ Name}},
 hw16srv()
 end.

 hw16() ->
 Pid = spawn(fun hw16srv/0),
 Sid = self(),
 Pid ! {Sid, {name, "alice"}},
 receive
 {Pid, {reply, Msg}} ->
 io:format("Client receive: ~p ~n", [Msg])
 end.

用到的关键字和上一段程序是一样的：创建进程spawn，发送消息!，接收消息receive，区别仅在于消息的格式。本段程序在消息的前面加上客户端进程的pid，让服务端进程知道消息是由哪个进程发过来的。Erlang似乎没有获知消息来源的机制，因此需要手工把发送方的pid写到消息中，方便接收方使用。

在hw16/0中，使用了self()来获得本进程的pid，然后本进程pid填到消息中，发给服务端，然后等待服务端发过来的消息，收到后就显示出来。

hw16srv/0中则是接收消息，然后提取对方发过来的名字，在前面加上"welcome"，然后发回给客户端。

进程间的消息：RPC

RPC是远程过程调用的缩写，也就是让另一个地方的程序帮你执行，然后把结果返回给你。 Erlang中的发送请求和等待回应可以封装为一个rpc/2的函数：

 rpc(Pid, Request) ->
 Pid ! {self(), Request},
 receive
 {Pid, Response} ->
 Response
 end.

 hw16b() ->
 Pid = spawn(fun hw16srv/0),
 {reply, Reply} = rpc(Pid, {name, "alice"}),
 io:format("Client receive: ~p ~n", [Reply]).

rpc/2把发送请求和等待回应包装起来，用起来更方便了

进程间的消息：引用

上面的rpc有个两个问题：第一个问题，是当传入的第一个参数不是一个pid，而是一个注册了的进程名，信息虽然也能发出去，返回的信息却是pid而不是注册名，无法匹配 {Pid, Response} ，因而函数会永远等待下去而不返回。第二个问题，如果本线程给远方线程发送了几个请求，对方发回了几个回复，那就搞不清哪个回复是对应哪个请求的了。解决这两个问题的方法是使用一个“引用”，如下：

 rpc2(Pid, Request) ->
 Ref = make_ref(),
 Pid ! { {self(), Ref}, Request},
 receive
 {Ref, Reply} ->
 Reply
 end.

 hw18srv() ->
 receive
 { {From, Ref}, {name, Name}} ->
 io:format("Server receive: ~p ~n", [Name]),
 From ! {Ref, {reply, "Welcome, " ++ Name}},
 hw16srv()
 end.

 hw18() ->
 Pid = spawn(fun hw18srv/0),
 {reply, Reply} = rpc2(Pid, {name, "alice"}),
 io:format("Client receive: ~p ~n", [Reply]).

rpc2/2就用了 make_ref() 来生成一个唯一的“引用”，make_ref/0生成的引用几乎是不会重复的，文档上的说明是要2E82次调用之后才会发生重复，这实际上是不可能的。

（在这里bs一下《Erlang编程指南》这本书的中文翻译，译得像机翻也就算了，错误还不少，像这个82在那本书上就被写成了28，我看书时还在怀疑，现代计算机进行2E28次运算，不就是几秒的事，这make_ref到底行不行。（在211页））

更新(2013年9月13日)

像上面写的那个rpc函数是不带超时选项的, 这在实际代码中有可能会永远都不返回, 程序就卡住了, 要尽量避免这种情况, 可以在后面加上 after 子句, 超时不候.

初识Erlang，Hello World（3）

Fri, 15 Mar 2013 00:00:00 +0000

今天不只要对World说Hello，还要对别人说Hello

 hw(Who) ->
 io:format("Hello ~p ~n", [Who]).

平平无奇的一个函数，对Who说Hello

如果要对一组人说Hello，可以这么做：

 hw10(L) ->
 [hw(X) || X <- L].

 hw10() ->
 L = ["ali", "bob", "cat"],
 hw10(L).

上面是用了列表解析的方法。

也可以用lists:map，效果和上面是一样的

 hw11(L) ->
 lists:map(fun hw/1, L).

 hw11() ->
 L = ["ali", "bob", "cat"],
 hw11(L).

另一个很相似的做法是lists:foreach：

 hw14(L) ->
 lists:foreach(fun hw/1, L).

 hw14() ->
 L = ["ali", "bob", "cat"],
 hw14(L).

这两种做法有什么区别呢？看看输出：

 2> helloworld:hw11().
 Hello "ali"
 Hello "bob"
 Hello "cat"
 [ok,ok,ok]

 10> helloworld:hw14().
 Hello "ali"
 Hello "bob"
 Hello "cat"
 ok

虽然map和foreach都是把同一个函数作用在列表的每一个元素上， map是会生成一个新的列表来存储结果并返回，（由于hw/1的值就是ok，所以会得到包含3个ok的列表）而foreach仅会返回ok。

不使用Lists模块的话，可以这么做：

 hw12([H|T]) ->
 hw(H),
 hw12(T);
 hw12([]) ->
 ok.

 hw12() ->
 L = ["ali", "bob", "cat"],
 hw12(L).

这是Erlang中最常见的Head|Tail写法了吧。

也可以用case改写上面的函数

 hw13(L) ->
 case L of
 [] -> ok;
 [H|T] -> hw(H),
 hw13(T)
 end.

 hw13() ->
 L = ["ali", "bob", "cat"],
 hw13(L).

更新(2013年9月13日)

如果数组很大, lists:foreach/1占用的内存会比lists:map/1少一些, 因为不需要生成一个同样大小的数组进行返回. 因此, 如果不需要返回值的话, 应该用lists:foreach/1, 或者lists:foldl/3, 或是自己写尾递归.

初识Erlang，Hello World (1)

Tue, 12 Mar 2013 00:00:00 +0000

这两天开始玩Erlang，咱们从Hello World开始吧。

先是要到官网http://www.erlang.org/download.html下载安装包，安装上，设置好系 PATH，然后打开命令行，输入erl，如果看到类似于

Eshell V5.10.1 (abort with ^G)
1>

的话，就表示Erlang安装成功。这东西叫做Erlang的Shell。

然后就是最经典的Hello World：

随便用一个文本编辑器输入：

 -module(helloworld).
 -export([hw/0]).

 hw() -> io:format("Hello World! ~n").

保存为helloworld.erl，然后在命令行下进入该文件所在目录，进入Erlang Shell，输入>后的命令：

 1> c(helloworld).
 {ok,helloworld}
 2> helloworld:hw().
 Hello World!
 ok

Yeah，Hello World完成！（我会告诉你我用了20分钟干这事么，下面是各种坑的介绍）

 % 首先，Erlang的注释符是百分号哦
 -module(helloworld).
 % -module是必要的，这可不是Bash或Python，上来就可以Echo或Print
 % 然后，helloworld 必须与文件名相同（除了不用加.erl）
 % 然后，行末的句点是必须的，虽然好不显眼

 -export([hw/0]).
 % -export也是必须的，这是用来说明哪些函数可以在外部被调用
 % 括号中必须是一个列表，换言之，加方括号
 % hw是函数名，斜杠后面是参数的数目，两者总是组合指明一个函数。
 % 参数数目不同的，即使同名，也是两个不同的函数
 % 还是记得句尾要加点

 hw() -> io:format("Hello World! ~n").
 % 这个是函数了
 % 函数名前面不用任何修饰，类似于其他语言中的Fun，def之类在这里是不必要的
 % 函数名是一个“原子”，换言之就是一个以小写字母开头的单词，可后继大小写字母下划线和@号
 % 或是你足够蛋疼的话，可以用单引号括起来的任意东西，比方说 '*&^%hw2'
 % 还有，不要拿fun当函数名，这个词另有用途
 % 函数名后面加括号，如果有参数，写在括号中
 % 括号后是 -> 这不是C语言中的指针，而是表示后面是函数的内容了
 % io:format可以当print，其实就是io模块里的format函数
 % 看清楚模块名和函数名之间是冒号，别弄成其他语言中的点
 % 双引号中是字符串，Erlang中的字符串实质上是数组
 % ~n是换行，用波浪线转义
 % 最后还是别忘记了是句点

这个erl文件的坑说完了，然后是Erlang Shell中的。

想用erl xxxxx.erl来执行是徒劳的，这货不是sh也不是python也不是pl，这么做你会进入Erlang Shell。

然后先是要c(helloworld).编译，记得不要忘记句点。然后同一个目录下就会出现一个同名的beam文件。

然后键入helloworld:hw().，回车没反应？又忘记句点了，补上，Hello World终于蹦出来了。

初识Erlang，Hello World (2)

Tue, 12 Mar 2013 00:00:00 +0000

昨天费了老大劲终于把Hello World打出来了，今天我们继续。

说N遍Hello World，递归的使用

Hello World说一遍怎么够呢，说N遍吧。代码如下：

 -module(helloworld).
 -export([hw3/1]).

 % 打印N遍Hello world
 hw3(N) when N > 0 ->
 io:format("Hello World ~n"),
 hw3(N-1);

 hw3(0) -> ok.

这有什么好坑的呢：

 hw3(N) when N > 0 ->

when后面是一个断言(guard)，仅在它为true时函数会被执行。

断言所能使用的语句是受限的，不能用自定义的函数。

 io:format("Hello World ~n"),
 hw3(N-1);

这一个函数体有多条语句，中间需要用逗号隔开

 hw3(0) -> ok.

hw3/1这个函数有几个函数子句，根据参数的模式识别和when保护元的值来选择使用函数体。

不同的函数体之间使用分号，最后一个末尾使用句点。

啥都不干用什么好呢？stackoverflow 上说用ok. 那就用ok吧。

再说N遍Hello World，使用case

如果不想用多个函数子句的话，可以用case

 hw5(N) ->
 case N of
 X when X > 0 ->
 io:format("Hello World ~n"),
 hw5(N-1);
 0 -> ok
 end.

case的语法是：

 case 条件表达式 of ->
 模式1 -> 语句段1;
 模式2 -> 语句段2;
 ....
 模式N -> 语句段N
 end

继续一行一行看：

 case N of

N是条件表达式，也就是说运行case中的哪一条子句会根据N的值来决定。

只有一个子句会被执行，这点跟C语言不一样。

而且如果全部子句的模式匹配都失败的话，会抛出错误。所以要考虑是否使用catch all的语句。

条件表达式与子句之间是用of来分隔的，注意不要顺手打冒号了。

 X when X > 0 ->

模式后面可以接when，也可以不用。

这一行是这么运行的：首先是对X和N进行模式匹配，即X=N，匹配是成功的，因为变量X没有赋值，所以X绑定到N，然后由于保卫元X>0为true，所以执行该子句。

 io:format("Hello World ~n"),
 hw5(N-1);

注意模式与语句段之间是用 -> 分开的，中间的case语句段需要以分号结束

 0 -> ok

递归结束条件，不可忘记的。最后一个case子句，也就是end之前不需要加标点。

 end.

case语句需要以end结束，后面这个句点是表示hw5整个函数的结束，不是case语法的一部分

继续说Hello World，使用if

if可以视为没有条件表达式和of的case

 hw6(N) ->
 if
 N > 0 ->
 io:format("Hello World ~n"),
 hw5(N-1);
 N == 0 ->
 ok
 end.

if的语法格式是：

 if
 保护元1 -> 语句1;
 保护元2 -> 语句2;
 .......
 保护元N -> 语句N
 end

if会执行第一个断言为真的语句。

要注意的东西跟case没什么区别，就不啰嗦了。

继续Hello World，使用列表解析

这似乎是最简洁的做法了

 hw7(N) ->
 [hw() || _ <- lists:seq(1, N) ].

这句话换相当于Python中的 [hw() for _ in range(1, N + 1)]。

意思是把（1，2，3…N）中的每一个值都装到变量_之后，运行hw()。由于hw中不调用 seq中产生的值，所以拿_这样的一个坑来装。

lists:seq是产生一个连接序列的数组，与Python中的range不同的是，它是既包头又包尾的，也是就说产生（1，2，3…N）。

继续Hello World，山寨for

Erlang最令人觉得奇怪的是它没有循环语句，不过这不妨碍我们直接山寨一个。

 for(I, N, F) when I < N ->
 F(),
 for(I + 1, N, F);
 for(N, N, F) ->
 F().

 hw8(N) ->
 for(1, N, fun hw/0).

 hw9(N) ->
 for(1, N, fun() -> hw() end).

这个山寨的for用了高阶函数的概念，它的F参数是是一个函数。注意hw8/1和hw9/1中的写法，我碰壁了好久，后来问了程序老大才解决的。

hw8/1是把函数名当参数后用，必须要使用fun关键词，而且要指明函数的目数，这与Python不一样。Python一个函数名只能绑定一个函数，给出名字就唯一确定了绑定对象。而Erlang允许同名不同目的函数，所以要指明目数。

hw9/1则是产生一个匿名函数作为参数，注意匿名函数的写法。以fun作为函数名，其余跟一般函数没什么区别。注意fun后面的括号不要漏掉，即使没有参数。

更新(2013年9月13日)

函数匹配是有顺序的, 像这篇最开头的hw/3, 如果把hw3(0)写在前面, 就可以不需要when N > 0了. 但这么做代码并不健壮, 遇上 N<0 就会出死循环. 因此, 还是加上when N > 0吧.

Erlang on cnDenis的笔记

【Erlang】lists:all/2 和 lists:any/2 对于空列表运算结果是啥?

lists:all(F, []) = true

lists:any(F, []) = false

【Erlang】Erlang虚拟机的内部时钟

Erlang内部时钟的特点

Erlang内部时钟的应用

erlang:now() 的特点

关闭内部时钟自动修正

erlang:now() vs os:timestamp()

【Erl代码片段】start_timer/3 发送的消息中的TimerRef的用途

【Erl代码片段】简易的并行版lists:map/2

【Erlang】ETS的并发性能调节选项

【Erlang】gen_server terminate的坑

OTP监控树笔记

【Erl代码片段】cowboy的一处大小写处理代码

【Erl代码片段】更快的proplists:get_value/3

Erlang数据项的size

erlang:external_size/1

erts_debug:flat_size/1 和 erts_debug:size/1

erlang:tuple_size/1

erlang:byte_size/1 和 erlang:bit_size/1

Erlang中IPv4地址与整数的转换

Erlang的大小比较

Erlang的静态代码检查

建立PLT文件

编译代码

运行检查

Erlang中的长度

len阵营

size阵营

更新(2013年9月13日)

Erlang中的原子、字符串和二进制串

原子

字符串

二进制串

gen_server笔记

gen_server模板

启动服务器

使用服务器

call

cast

原生消息

停止服务器

更新(2013年9月13日)

初识Erlang，Hello World（4）

进程间的消息：单向接收

进程间的消息：相互对话

进程间的消息：RPC

进程间的消息：引用

更新(2013年9月13日)

初识Erlang，Hello World（3）

更新(2013年9月13日)

初识Erlang，Hello World (1)

初识Erlang，Hello World (2)

说N遍Hello World，递归的使用

再说N遍Hello World，使用case

继续说Hello World，使用if

继续Hello World，使用列表解析

继续Hello World，山寨for

更新(2013年9月13日)

`erlang:external_size/1`

`erts_debug:flat_size/1` 和 `erts_debug:size/1`

`erlang:tuple_size/1`

`erlang:byte_size/1` 和 `erlang:bit_size/1`