gen_event行为模式规定了怎么处理日志事件
该行为模式和gen_server不同 一个gen_server的实现只能绑定一个回调模块
而gen_event则可以回调多个模块 这个和在java中注册成为一个事件的监听者道理是一样的
一个日志事件(event)会分发给多个注册了的处理者(handler,gen_event行为模式的实现模块)
gen_event由start_link/0或/1进行初始化
一般使用start_link/1(可以使用start 用start_linik是为了和监督者连接起来)
Types:
EventMgrName = {local,Name} | {global,GlobalName} | {via,Module,ViaName}
Name = atom()
GlobalName = ViaName = term()
Result = {ok,Pid} | {error,{already_started,Pid}}
Pid = pid()
使用的时候用诸如:
gen_event:start_link({local, ?SERVER}).
的形式,注册一个名字叫?SERVER的本地事件管理器(以后的notify call等函数都要通过这个?SERVER来使用 (当然也可以使用返回的pid)
要增加一个handler用:
Types:
EventMgr = Name | {Name,Node} | {global,GlobalName} | {via,Module,ViaName} | pid()
Name = Node = atom()
GlobalName = ViaName = term()
Handler = Module | {Module,Id}
Module = atom()
Id = term()
Args = term()
Result = ok | {'EXIT',Reason} | term()
Reason = term()
这个就是为?SERVER(或者表示事件管理器的pid)命令的事件管理器增加一个 handler
handler就是实现了gen_event行为模式的模块的模块名
那么对应的反操作删除就是 参数一致。
Types:
EventMgrRef = Name | {Name,Node} | {global,GlobalName} | {via,Module,ViaName} | pid()
Name = Node = atom()
GlobalName = ViaName = term()
Handler = Module | {Module,Id}
Module = atom()
Id = term()
Args = term()
Result = term() | {error,module_not_found} | {'EXIT',Reason}
Reason = term()
接下去是函数的调用和对应模块(实现了gen_event行为模式的模块)内的回调的对应
gen_event:notify/2 gen_event:sync_notify/2----> module:handle_event/2
gen_event:call/3,4 ---->module:handle_call/2
module:handle_info/2用来接收没有定义的event(没有一个和module:handle_event匹配的)或者系统消息
一般使用gen_event:notify/2就足够了,其他的在doc里有详细解释
以下是一个例子:
这个例子来自erlang/OTP并发编程实战 是一个完整的小程序 我这边把日志模块单独抽取了出来
完整的程序代码见:
首先是产生事件源的代码:
-module(sc_event). -export([start_link/0, add_handler/2, delete_handler/2, lookup/1, create/2, replace/2, delete/1]). -define(SERVER, ?MODULE). start_link() -> gen_event:start_link({local, ?SERVER}). add_handler(Handler, Args) -> gen_event:add_handler(?SERVER, Handler, Args). delete_handler(Handler, Args) -> gen_event:delete_handler(?SERVER, Handler, Args). lookup(Key) -> gen_event:notify(?SERVER, {lookup, Key}). create(Key, Value) -> gen_event:notify(?SERVER, {create, {Key, Value}}). replace(Key, Value) -> gen_event:notify(?SERVER, {replace, {Key, Value}}). delete(Key) -> gen_event:notify(?SERVER, {delete, Key}).
这段代码不难理解 模块名是sc_event 里面封装了gen_event的调用
gen_event初始化时注册了 和模块同名的本地事件管理器 然后接下去的notify方法调用的第一个参数就是这个管理器的名字
通过add_handler和delete_handler对处理模块进行移入和移出操作
接下去的代码是自定义的日志处理(handler) 实现了gen_event行为模式:
-module(sc_event_logger). -behaviour(gen_event). -export([add_handler/0, delete_handler/0]). -export([init/1, handle_event/2, handle_call/2, handle_info/2, code_change/3, terminate/2]). -record(state, {}). add_handler() -> sc_event:add_handler(?MODULE, []). delete_handler() -> sc_event:delete_handler(?MODULE, []). init([]) -> {ok, #state{}}. handle_event({create, {Key, Value}}, State) -> error_logger:info_msg("sc_event_logger:create(~w, ~w)~n", [Key, Value]), {ok, State}; handle_event({lookup, Key}, State) -> error_logger:info_msg("sc_event_logger:lookup(~w)~n", [Key]), {ok, State}; handle_event({delete, Key}, State) -> error_logger:info_msg("sc_event_logger:delete(~w)~n", [Key]), {ok, State}; handle_event({replace, {Key, Value}}, State) -> error_logger:info_msg("sc_event_logger:replace(~w, ~w)~n", [Key, Value]), {ok, State}. handle_call(_Request, State) -> Reply = ok, {ok, Reply, State}. handle_info(_Info, State) -> {ok, State}. terminate(_Reason, _State) -> ok. code_change(_OldVsn, State, _Extra) -> {ok, State}.
这边也比较好理解 各个handle_event用来处理事件源中发出的不同事件
单独调用如下:
1> c(sc_event). {ok,sc_event} 2> c(sc_event_logger). {ok,sc_event_logger} 3> sc_event:start_link(). {ok,<0.45.0>} 4> sc_event_logger:add_handler(). ok 5> sc_event:lookup("test"). ok 6> =INFO REPORT==== 14-Jul-2013::11:04:38 === sc_event_logger:lookup([116,101,115,116])