Erlang打包独立环境

最近公司代码需要在非erlang的系统上执行,需要能在独立的环境里运行erlang。研究甚久,于是写下这篇博文。国内用erlang的朋友不多,希望这篇blog能对有需要的朋友起到参考作用。

 

Application-Vsn/ebin
/include
/priv
/src
/Application-Vsn.rel

 

以上是代码的目录表.

 

{release, {“nextim”, “2.0″},
{erts, “5.7.5″},
[{kernel, “2.12.3”},
{stdlib, “1.15.3”},
{sasl, “2.1.5.3”}]
}.

 

以上是Application-Vsn.rel的内容,[]中是代码本身需要的lib。

 

1.执行erl -pa ./ebin . 这一步会生成nextim-2.boot文件

1> systools:make_script(nextim-2″, [local]).
ok

 

2.erl -boot nextim-2 . 这一步会生成nextim-2.tar.gz

systools:make_tar(“nextim-2″).

 

3.现在建议把tar.gz文件放到独立的路径里 这样不会影响Application-Vsn文件夹 ,然后解压 并进入目录, 复制erlang系统目录里的 erts-5.7.5 到当前目录

 

4.建立bin文件夹 复制  erts-5.7.5/bin/start bin/ 编辑 bin/startROOTDIR为当前目录的路径

 

5.复制erts-5.7.5/bin/run_erl erts-5.7.2/bin/erlbin 并且如同上一步一样修改ROOTDIR.

 

6.复制 $ERLDIR/bin/start_sasl.boot 到  bin/start.boot.

 

7. echo "5.7.5 2.0" > releases/start_erl.data.

 

6.执行bin文件里的erl

release_handler:create_RELEASES(“$ROOTDIR”, “$ROOTDIR/releases/”, “$ROOTDIR/releases/nextim-2.rel”, []).

 

7.再把自己的项目文件复制到lib中  然后启动时 -pa参数是 lib文件夹. 完成这一步,就能独立出erlang环境了。

 
 

以上内容 参考自

http://spawnlink.com/articles/an-introduction-to-releases-with-erlybank/

http://streamhacker.com/2009/07/02/how-to-create-an-erlang-first-target-system/

ETS named_table

new(Name, Options) -> tid() | atom()

  • Name = atom()
  • Options = [Option]
  •  Option = Type | Access | named_table | {keypos,Pos} | {heir,pid(),HeirData} | {heir,none} | {write_concurrency,bool()}
  •   Type = set | ordered_set | bag | duplicate_bag
  •   Access = public | protected | private
  •   Pos = int()
  •   HeirData = term()
Creates a new table and returns a table identifier which can be used in subsequent operations. The table identifier can be sent to other processes so that a table can be shared between different processes within a node.
The parameter Options is a list of atoms which specifies table type, access rights, key position and if the table is named or not. If one or more options are left out, the default values are used. This means that not specifying any options ([]) is the same as specifying [set,protected,{keypos,1},{heir,none},{write_concurrency,false}].
  • set The table is a set table – one key, one object, no order among objects. This is the default table type.
  • ordered_set The table is a ordered_set table – one key, one object, ordered in Erlang term order, which is the order implied by the < and > operators. Tables of this type have a somewhat different behavior in some situations than tables of the other types. Most notably the ordered_set tables regard keys as equal when they compare equal, not only when they match. This means that to an ordered_set, the integer()1 and the float()1.0 are regarded as equal. This also means that the key used to lookup an element not necessarily matches the key in the elements returned, if float()‘s and integer()‘s are mixed in keys of a table.
  • bag The table is a bag table which can have many objects, but only one instance of each object, per key.
  • duplicate_bag The table is a duplicate_bag table which can have many objects, including multiple copies of the same object, per key.
  • public Any process may read or write to the table.
  • protected The owner process can read and write to the table. Other processes can only read the table. This is the default setting for the access rights.
  • private Only the owner process can read or write to the table.
  • named_table If this option is present, the name Name is associated with the table identifier. The name can then be used instead of the table identifier in subsequent operations.
  • {keypos,Pos} Specfies which element in the stored tuples should be used as key. By default, it is the first element, i.e. Pos=1. However, this is not always appropriate. In particular, we do not want the first element to be the key if we want to store Erlang records in a table.
    Note that any tuple stored in the table must have at least Pos number of elements.
  • {heir,Pid,HeirData} | {heir,none}
    Set a process as heir. The heir will inherit the table if the owner terminates. The message {'ETS-TRANSFER',tid(),FromPid,HeirData} will be sent to the heir when that happens. The heir must be a local process. Default heir is none, which will destroy the table when the owner terminates.
  • {write_concurrency,bool()} Performance tuning. Default is false, which means that the table is optimized towards concurrent read access. An operation that mutates (writes to) the table will obtain exclusive access, blocking any concurrent access of the same table until finished. If set to true, the table is optimized towards concurrent write access. Different objects of the same table can be mutated (and read) by concurrent processes. This is achieved to some degree at the expense of single access and concurrent reader performance. Note that this option does not change any guarantees about atomicy and isolation. Functions that makes such promises over several objects (like insert/2) will gain less (or nothing) from this option.
    Table type ordered_set is not affected by this option in current implementation.

xmerl_scan


xmerl_scan

模块 MODULE
xmerl_scan
 
模块摘要 MODULE SUMMARY
This module is the interface to the XML parser, it handles XML 1.0.
 
描述 DESCRIPTION
This module is the interface to the XML parser, it handles XML 1.0. The XML parser is activated through xmerl_scan:string/[1,2] or xmerl_scan:file/[1,2]. It returns records of the type defined in xmerl.hrl. 参考:tutorial on customization functions.

数据类型 DATA TYPES

global_state()
The global state of the scanner, represented by the #xmerl_scanner{} record.
option_list()
Options allow to customize the behaviour of the scanner. 参考:tutorial on customization functions.
Possible options are:

{acc_fun, Fun}
Call back function to accumulate contents of entity.
{continuation_fun, Fun} | {continuation_fun, Fun, ContinuationState}
Call back function to decide what to do if the scanner runs into EOF before the document is complete.
{event_fun, Fun} | {event_fun, Fun, EventState}
Call back function to handle scanner events.
{fetch_fun, Fun} | {fetch_fun, Fun, FetchState}
Call back function to fetch an external resource.
{hook_fun, Fun} | {hook_fun, Fun, HookState}
Call back function to process the document entities once identified.
{close_fun, Fun}
Called when document has been completely parsed.
{rules, ReadFun, WriteFun, RulesState} | {rules, Rules}
Handles storing of scanner information when parsing.
{user_state, UserState}
Global state variable accessible from all customization functions
{fetch_path, PathList}
PathList is a list of directories to search when fetching files. If the file in question is not in the fetch_path, the URI will be used as a file name.
{space, Flag}
‘preserve’ (default) to preserve spaces, ‘normalize’ to accumulate consecutive whitespace and replace it with one space.
{line, Line}
To specify starting line for scanning in document which contains fragments of XML.
{namespace_conformant, Flag}
Controls whether to behave as a namespace conformant XML parser, ‘false’ (default) to not otherwise ‘true’.
{validation, Flag}
Controls whether to process as a validating XML parser: ‘off’ (default) no validation, or validation ‘dtd’ by DTD or ‘schema’ by XML Schema. ‘false’ and ‘true’ options are obsolete (i.e. they may be removed in a future release), if used ‘false’ equals ‘off’ and ‘true’ equals ‘dtd’.
{schemaLocation, [{Namespace,Link}|…]}
Tells explicitly which XML Schema documents to use to validate the XML document. Used together with the {validation,schema} option.
{quiet, Flag}
Set to ‘true’ if xmerl should behave quietly and not output any information to standard output (default ‘false’).
{doctype_DTD, DTD}
Allows to specify DTD name when it isn’t available in the XML document. This option has effect only together with {validation,’dtd’ option.
{xmlbase, Dir}
XML Base directory. If using string/1 default is current directory. If using file/1 default is directory of given file.
{encoding, Enc}
Set default character set used (default UTF-8). This character set is used only if not explicitly given by the XML declaration.

导出函数 EXPORTS

Function to accumulate and normalize whitespace.
 
For controlling the ContinuationState, to be used in a continuation function, and called when the parser encounters the end of the byte stream. 查看 tutorial on customization functions.
 
Equivalent to event_state(EventState, S).
 
For controlling the EventState, to be used in an event function, and called at the beginning and at the end of a parsed entity. 查看 tutorial on customization functions.
 
Equivalent to fetch_state(FetchState, S).
 
For controlling the FetchState, to be used in a fetch function, and called when the parser fetch an external resource (eg. a DTD). 查看 tutorial on customization functions.
 
类型说明:
Rest = list()
Equivalent to file(Filename, []).
类型说明:
Rest = list()
Parse file containing an XML document
 
Equivalent to hook_state(HookState, S).
 
For controlling the HookState, to be used in a hook function, and called when the parser has parsed a complete entity. 查看 tutorial on customization functions.
 
Equivalent to rules_state(RulesState, S).
 
For controlling the RulesState, to be used in a rules function, and called when the parser store scanner information in a rules database. 查看 tutorial on customization functions.
 
类型说明:
Rest = list()
Equivalent to string(Test, []).
 
类型说明:
Rest = list()
Parse string containing an XML document
 
Equivalent to user_state(UserState, S).
 
For controlling the UserState, to be used in a user function. 查看 tutorial on customization functions.

Erlang OTP 之 Application

application

Generic OTP application functions

In OTP, application denotes a component implementing some specific functionality, that can be started and stopped as a unit, and which can be re-used in other systems as well. This module interfaces the application controller, a process started at every Erlang runtime system, and contains functions for controlling applications (for example starting and stopping applications), and functions to access information about applications (for example configuration parameters).
An application is defined by an application specification. The specification is normally located in an application resource file called Application.app, where Application is the name of the application. Refer to app(4) for more information about the application specification.
This module can also be viewed as a behaviour for an application implemented according to the OTP design principles as a supervision tree. The definition of how to start and stop the tree should be located in an application callback module exporting a pre-defined set of functions.
Refer to OTP Design Principles for more information about applications and behaviours.

Functions


get_all_env() -> Env

get_all_env(Application) -> Env

  • Application = atom()
  • Env = [{Par,Val}]
  •  Par = atom()
  •  Val = term()
Returns the configuration parameters and their values for Application. If the argument is omitted, it defaults to the application of the calling process.
If the specified application is not loaded, or if the process executing the call does not belong to any application, the function returns [].

get_all_key() -> {ok, Keys} | []

get_all_key(Application) -> {ok, Keys} | undefined

  • Application = atom()
  • Keys = [{Key,Val}]
  •  Key = atom()
  •  Val = term()
Returns the application specification keys and their values for Application. If the argument is omitted, it defaults to the application of the calling process.
If the specified application is not loaded, the function returns undefined. If the process executing the call does not belong to any application, the function returns [].

get_application() -> {ok, Application} | undefined

get_application(Pid | Module) -> {ok, Application} | undefined

  • Pid = pid()
  • Module = atom()
  • Application = atom()
Returns the name of the application to which the process Pid or the module Module belongs. Providing no argument is the same as calling get_application(self()).
If the specified process does not belong to any application, or if the specified process or module does not exist, the function returns undefined.

get_env(Par) -> {ok, Val} | undefined

get_env(Application, Par) -> {ok, Val} | undefined

  • Application = atom()
  • Par = atom()
  • Val = term()
Returns the value of the configuration parameter Par for Application. If the application argument is omitted, it defaults to the application of the calling process.
If the specified application is not loaded, or the configuration parameter does not exist, or if the process executing the call does not belong to any application, the function returns undefined.

get_key(Key) -> {ok, Val} | undefined

get_key(Application, Key) -> {ok, Val} | undefined

  • Application = atom()
  • Key = atom()
  • Val = term()
Returns the value of the application specification key Key for Application. If the application argument is omitted, it defaults to the application of the calling process.
If the specified application is not loaded, or the specification key does not exist, or if the process executing the call does not belong to any application, the function returns undefined.

load(AppDescr) -> ok | {error, Reason}

load(AppDescr, Distributed) -> ok | {error, Reason}

  • AppDescr = Application | AppSpec
  •  Application = atom()
  •  AppSpec = {application,Application,AppSpecKeys}
  •   AppSpec = [{Key,Val}]
  •    Key = atom()
  •    Val = term()
  • Distributed = {Application,Nodes} | {Application,Time,Nodes} | default
  •  Nodes = [node() | {node(),..,node()}]
  •  Time = integer() > 0
  • Reason = term()
Loads the application specification for an application into the application controller. It will also load the application specifications for any included applications. Note that the function does not load the actual Erlang object code.
The application can be given by its name Application. In this case the application controller will search the code path for the application resource file Application.app and load the specification it contains.
The application specification can also be given directly as a tuple AppSpec. This tuple should have the format and contents as described in app(4).
If Distributed == {Application,[Time,]Nodes}, the application will be distributed. The argument overrides the value for the application in the Kernel configuration parameter distributed. Application must be the name of the application (same as in the first argument). If a node crashes and Time has been specified, then the application controller will wait for Time milliseconds before attempting to restart the application on another node. If Time is not specified, it will default to 0 and the application will be restarted immediately.
Nodes is a list of node names where the application may run, in priority from left to right. Node names can be grouped using tuples to indicate that they have the same priority. Example:

This means that the application should preferably be started at cp1@cave. If cp1@cave is down, the application should be started at either cp2@cave or cp3@cave.
If Distributed == default, the value for the application in the Kernel configuration parameter distributed will be used.

loaded_applications() -> [{Application, Description, Vsn}]

  • Application = atom()
  • Description = string()
  • Vsn = string()
Returns a list with information about the applications which have been loaded using load/1,2, also included applications. Application is the application name. Description and Vsn are the values of its description and vsn application specification keys, respectively.

permit(Application, Bool) -> ok | {error, Reason}

  • Application = atom()
  • Bool = bool()
  • Reason = term()
Changes the permission for Application to run at the current node. The application must have been loaded using load/1,2 for the function to have effect.
If the permission of a loaded, but not started, application is set to false, start will return ok but the application will not be started until the permission is set to true.
If the permission of a running application is set to false, the application will be stopped. If the permission later is set to true, it will be restarted.
If the application is distributed, setting the permission to false means that the application will be started at, or moved to, another node according to how its distribution is configured (see load/2 above).
The function does not return until the application is started, stopped or successfully moved to another node. However, in some cases where permission is set to true the function may return ok even though the application itself has not started. This is true when an application cannot start because it has dependencies to other applications which have not yet been started. When they have been started, Application will be started as well.
By default, all applications are loaded with permission true on all nodes. The permission is configurable by using the Kernel configuration parameter permissions.

set_env(Application, Par, Val) -> ok

set_env(Application, Par, Val, Timeout) -> ok

  • Application = atom()
  • Par = atom()
  • Val = term()
  • Timeout = int() | infinity
Sets the value of the configuration parameter Par for Application.
set_env/3 uses the standard gen_server timeout value (5000 ms). A Timeout argument can be provided if another timeout value is useful, for example, in situations where the application controller is heavily loaded.

Warning!

Use this function only if you know what you are doing, that is, on your own applications. It is very application and configuration parameter dependent when and how often the value is read by the application, and careless use of this function may put the application in a weird, inconsistent, and malfunctioning state.

start(Application) -> ok | {error, Reason}

start(Application, Type) -> ok | {error, Reason}

  • Application = atom()
  • Type = permanent | transient | temporary
  • Reason = term()
Starts Application. If it is not loaded, the application controller will first load it using load/1. It will make sure any included applications are loaded, but will not start them. That is assumed to be taken care of in the code for Application.
The application controller checks the value of the application specification key applications, to ensure that all applications that should be started before this application are running. If not, {error,{not_started,App}} is returned, where App is the name of the missing application.
The application controller then creates an application master for the application. The application master is the group leader of all the processes in the application. The application master starts the application by calling the application callback function Module:start/2 as defined by the application specification key mod.
The Type argument specifies the type of the application. If omitted, it defaults to temporary.
  • If a permanent application terminates, all other applications and the entire Erlang node are also terminated.
  • If a transient application terminates with Reason == normal, this is reported but no other applications are terminated. If a transient application terminates abnormally, all other applications and the entire Erlang node are also terminated.
  • If a temporary application terminates, this is reported but no other applications are terminated.
Note that it is always possible to stop an application explicitly by calling stop/1. Regardless of the type of the application, no other applications will be affected.
Note also that the transient type is of little practical use, since when a supervision tree terminates, the reason is set to shutdown, not normal.

start_type() -> StartType | local | undefined

  • StartType = normal | {takeover,Node} | {failover,Node}
  •  Node = node()
This function is intended to be called by a process belonging to an application, when the application is being started, to determine the start type which is either StartType or local.
See Module:start/2 for a description of StartType.
local is returned if only parts of the application is being restarted (by a supervisor), or if the function is called outside a startup.
If the process executing the call does not belong to any application, the function returns undefined.

stop(Application) -> ok | {error, Reason}

  • Application = atom()
  • Reason = term()
Stops Application. The application master calls Module:prep_stop/1, if such a function is defined, and then tells the top supervisor of the application to shutdown (see supervisor(3)). This means that the entire supervision tree, including included applications, is terminated in reversed start order. After the shutdown, the application master calls Module:stop/1. Module is the callback module as defined by the application specification key mod.
Last, the application master itself terminates. Note that all processes with the application master as group leader, i.e. processes spawned from a process belonging to the application, thus are terminated as well.
When stopped, the application is still loaded.
In order to stop a distributed application, stop/1 has to be called on all nodes where it can execute (that is, on all nodes where it has been started). The call to stop/1 on the node where the application currently executes will stop its execution. The application will not be moved between nodes due to stop/1 being called on the node where the application currently executes before stop/1 is called on the other nodes.

takeover(Application, Type) -> ok | {error, Reason}

  • Application = atom()
  • Type = permanent | transient | temporary
  • Reason = term()
Performs a takeover of the distributed application Application, which executes at another node Node. At the current node, the application is restarted by calling Module:start({takeover,Node},StartArgs). Module and StartArgs are retrieved from the loaded application specification. The application at the other node is not stopped until the startup is completed, i.e. when Module:start/2 and any calls to Module:start_phase/3 have returned.
Thus two instances of the application will run simultaneously during the takeover, which makes it possible to transfer data from the old to the new instance. If this is not acceptable behavior, parts of the old instance may be shut down when the new instance is started. Note that the application may not be stopped entirely however, at least the top supervisor must remain alive.
See start/1,2 for a description of Type.

unload(Application) -> ok | {error, Reason}

  • Application = atom()
  • Reason = term()
Unloads the application specification for Application from the application controller. It will also unload the application specifications for any included applications. Note that the function does not purge the actual Erlang object code.

unset_env(Application, Par) -> ok

unset_env(Application, Par, Timeout) -> ok

  • Application = atom()
  • Par = atom()
  • Timeout = int() | infinity
Removes the configuration parameter Par and its value for Application.
unset_env/2 uses the standard gen_server timeout value (5000 ms). A Timeout argument can be provided if another timeout value is useful, for example, in situations where the application controller is heavily loaded.

Warning!

Use this function only if you know what you are doing, that is, on your own applications. It is very application and configuration parameter dependent when and how often the value is read by the application, and careless use of this function may put the application in a weird, inconsistent, and malfunctioning state.

which_applications() -> [{Application, Description, Vsn}]

which_applications(Timeout) -> [{Application, Description, Vsn}]

  • Application = atom()
  • Description = string()
  • Vsn = string()
  • Timeout = int() | infinity
Returns a list with information about the applications which are currently running. Application is the application name. Description and Vsn are the values of its description and vsn application specification keys, respectively.
which_applications/0 uses the standard gen_server timeout value (5000 ms). A Timeout argument can be provided if another timeout value is useful, for example, in situations where the application controller is heavily loaded.

CALLBACK MODULE

The following functions should be exported from an application callback module.

Functions


Module:start(StartType, StartArgs) -> {ok, Pid} | {ok, Pid, State} | {error, Reason}

  • StartType = normal | {takeover,Node} | {failover,Node}
  •  Node = node()
  • StartArgs = term()
  • Pid = pid()
  • State = term()
This function is called whenever an application is started using application:start/1,2, and should start the processes of the application. If the application is structured according to the OTP design principles as a supervision tree, this means starting the top supervisor of the tree.
StartType defines the type of start:
  • normal if its a normal startup.
  • normal also if the application is distributed and started at the current node due to a failover from another node, and the application specification key start_phases == undefined.
  • {takeover,Node} if the application is distributed and started at the current node due to a takeover from Node, either because application:takeover/2 has been called or because the current node has higher priority than Node.
  • {failover,Node} if the application is distributed and started at the current node due to a failover from Node, and the application specification key start_phases /= undefined.
StartArgs is the StartArgs argument defined by the application specification key mod.
The function should return {ok,Pid} or {ok,Pid,State} where Pid is the pid of the top supervisor and State is any term. If omitted, State defaults to []. If later the application is stopped, State is passed to Module:prep_stop/1.

Module:start_phase(Phase, StartType, PhaseArgs) -> ok | {error, Reason}

  • Phase = atom()
  • StartType = normal | {takeover,Node} | {failover,Node}
  •  Node = node()
  • PhaseArgs = term()
  • Pid = pid()
  • State = state()
This function is used to start an application with included applications, when there is a need for synchronization between processes in the different applications during startup.
The start phases is defined by the application specification key start_phases == [{Phase,PhaseArgs}]. For included applications, the set of phases must be a subset of the set of phases defined for the including application.
The function is called for each start phase (as defined for the primary application) for the primary application and all included applications, for which the start phase is defined.
See Module:start/2 for a description of StartType.

Module:prep_stop(State) -> NewState

  • State = NewState = term()
This function is called when an application is about to be stopped, before shutting down the processes of the application.
State is the state returned from Module:start/2, or [] if no state was returned. NewState is any term and will be passed to Module:stop/1.
The function is optional. If it is not defined, the processes will be terminated and then Module:stop(State) is called.

Module:stop(State)

  • State = term()
This function is called whenever an application has stopped. It is intended to be the opposite of Module:start/2 and should do any necessary cleaning up. The return value is ignored.
State is the return value of Module:prep_stop/1, if such a function exists. Otherwise State is taken from the return value of Module:start/2.

Module:config_change(Changed, New, Removed) -> ok

  • Changed = [{Par,Val}]
  • New = [{Par,Val}]
  • Removed = [Par]
  •  Par = atom()
  •  Val = term()
This function is called by an application after a code replacement, if there are any changes to the configuration parameters.
Changed is a list of parameter-value tuples with all configuration parameters with changed values, New is a list of parameter-value tuples with all configuration parameters that have been added, and Removed is a list of all parameters that have been removed.

Erlang OTP 自定义behaviour

为什么要使用behaviour,如果您对erlang有所了解的话,就明白其中的好处。
可以做到代码通用,可以减少错误,可以使用很多成熟的久经考验的模式,可以减轻无谓的重复劳动等等。。
有些时候,你可能需要定义自己的behaviour,这可不仅仅是OTP的权力。
自己定义behaviour非常简单,仅仅需要几步。
下面是一个例子:

Erlang 代码
  1. -module(my_behaviour).  
  2.   
  3. -export([behaviour_info/1]).  
  4. behaviour_info(callbacks) ->  
  5.     [{init,1},  
  6.      {handle, 2}];  
  7. behaviour_info(_Other) ->  
  8.     undefined.  
  9.   
  10. -export([start/1, stop/0]).  
  11. start(Mod) ->  
  12.     State = Mod:init(0),  
  13.     {ok, State2} = Mod:handle(add,  State),  
  14.     io:format("state :~p~n", [State2]).  
  15. stop() ->  
  16.     stop.  

上面就定义了一个名叫my_behaviour的behaviour,其需要两个回调函数:init/1和handle/1,以后在使用这个 behaviour时,只需要export这两个回调函数即可。
如:

Erlang 代码
  1. -module(use_my_behaviour).  
  2. -behaviour(my_behaviour).  
  3. %%behaviour callback function  
  4. -export([init/1,  handle/2]).  
  5.   
  6. init(State) ->  
  7.       io:format("init ~p~n", [State]),  
  8.       State.  
  9.   
  10. handle(Request, State) ->  
  11.       io:format("handle request:~p state:~p", [Request, State]),  
  12.       State2 = State + 1,  
  13.       {ok, state2}.  


使用:

Erlang 代码
  1. $erl  
  2. > my_behaviour:start(use_my_behaviour).  

为了您的behaviour更易使用,您需要对behaviour的功用和回调函数的参数,返回值等进行详细的说明。具体可以参考OTP中 gen_server等behaviour的实现。

Erlang四大behaviour之三-gen_event

1. 事件处理规则

在OTP中,事件管理器是一个事件可以发送到的命名对象,一个事件可以是一个错误、一个警告、或者一些要写入日志的信息
在事件管理器中,有0个、一个或者多个事件处理器被安装,当事件管理器被一个事件通知时,这个事件将被安装在事件管理器中的事件处理器处理,
事件管理器用一个进程实现,事件处理器用回调模块实现。事件管理器本质上维护一个{Module, State}列表,每一个Module为一个事件处理器,而State为事件处理器的内部状态。

 

2. 例子

事件处理器的回调模块把错误信息写入终端
 
事件处理器的回调模块把错误信息写入文件
 

3. 启动事件管理器

调用
 
启动管理器,这个函数生成并连接到一个新进程,参数{local, error_man}指定名称,在这个例子中,事件管理器被局部注册为error_man
假如忽略名称,那么事件管理器不会被注册,它的PID将被使用。名称也可以是这种形式{global, Name},这样,事件管理器的名称是用global:register_name/2注册的。
假如事件管理器是监控树的一部分,那么gen_event:start_link必须被使用,也就是被监控树启动,而 gen_event:start启动单独的事件管理器,也就是事件管理器不是监控树的一部分。
 

4. 添加事件处理器

下面的例子显示怎样启动一个事件管理器和添加一个事件处理器
 
gen_event:add_handler(error_man, terminal_logger, [])为error_man添加处理器terminal_logger,事件管理器调用terminal_logger:init([])这个回调函数, []是参数,init要返回一个{ok, State},State是事件处理器的内部状态
这里,init不需要任何输入参数,对于terminal_logger,也没使用内部状态,对于file_logger,内部状态保存了打开的文 件描述符
 

5. 关于事件通知

 
error_man是事件管理器的名称,no_reply是事件,事件作为消息发送给事件管理器,当事件被收到时,事件管理器为每个安装的事件处理 器按安装次序调用handle_event(Event, State),这个函数期待返回{ok, State1},State1是事件处理器的新状态。
在terminal_logger中
 
在file_logger中
 

6. 删除一个事件处理器

gen_event:delete_handler(error_man, terminal_logger, []),这个函数向事件管理器error_man发送了一个消息,告诉他删除terminal_logger这个事件处理器,事件管理器将调用 terminal_logger:terminate([], State),参数[]是delete_handler的第三个参数,terminate以init相反的方向调用,以完成清理工作,返回值被忽略。
在terminal_logger中,没有清理动作
 
在file_logger中,文件描述符被关掉
 

7. 停止

当事件管理器被停止,它给每个注册的事件处理器调用terminate/2的机会,就好像事件处理器被删除一样。如果事件管理器是监控树的一部分, 不需要显示的停止事件管理器。当事件管理器作为单独进程使用时,则调用gen_event:stop(error_man).

Erlang四大behaviour之四 – Supervisor

1. 监督规则

一个监督者负责启动、停止、监控他的子进程。监督者的一个基本概念就是当必要的时候重启子进程保证它们的存活
哪个子进程要重启和被监控是由一个子规程列表决定的,子进程按照列表中指定的顺序启动,并按相反的顺序终止

 

2. 实例

监督者的回调模块
 
one_for_one是重启策略1和60定义了最大重启频率{ch3, …}是子规程

3. 重启策略

one_for_one
假如一个进程终止了,仅仅这个进程会被重启
one_for_all

假如一个进程停止了,所有其他子进程也要被停止,然后所有子进程,包括这个引发停止的子进程都被重启
rest_for_one
假如一个进程停止了,它后面的子进程,也就是以启动顺序来说这个被终止的进程后面的子进程都将被停止,然后他们又被启动。
 

4. 最大启动频率

监督者有一个内建机制限制在给定的时间间隔里的重启次数,这由子进程启动规程中的两个参数值决定,MaxR和MaxT,它们定义在回调函数init 中
 
如果在时间MaxT里重启次数大于MaxR ,监督者进程就停止它所有子进程,然后再终止自己。
当监督者进程终止了,那么更高级别的监督者要采取些动作,它或者重启被终止的监督者或者停止自己
这个重启机制的目的是预防一个进程因某种原因频繁的终止,然后简单的重启。

5. 子规范

下面的是类型定义
 
  • Id用来内部标识子规范
  • StartFunc是启动子进程时调用的函数,它将成为对supervisor:start_link, gen_server:start_link, gen_fsm:start_link or gen_event:start_link的调用
  • Restart标识一个进程终止后将怎样重启,一个permanent 进程总会被重启;一个temporary 进程从不会被重启;一个transient 进程仅仅当是不正常的被终止后才重启,例如非normal得退出原因
  • Shutdown 定义一个进程将怎样被终止,brutal_kill意味着子进程被exit(Child, kill)无条件的终止;一个整数值的超时时间意味着监督者告诉子进程通过调用exit(Child, shutdown)而被终止,然后等待一个返回的退出信号,假如在指定的时间里没有收到退出信号,那么子进程用exit(Child, kill)被无条件终止。
  • Type指定子进程是supervisor还是worker
  • Modules 是有一个元素的列表[Module],假如子进程是supervisor、gen_server 或 gen_fsm,那么Module 是回调模块的名称;假如子进程是gen_event,那么Modules 应该是dynamic
例如:子规范用于启动一个服务器ch3
 
子规范用于启动一个事件管理器
 
监督者然后根据子规程启动所有子进程,这个例子中是一个子进程ch3

6. 启动supervisor

像这样
 
启动
监督者进程调用init
 
并期待init返回{ok, StartSpec}
注意supervisor:start_link是同步的,它一直等到所有子进程都启动了才返回

7. 添加子进程

除静态监控树外,我们也可以通过supervisor:start_child(Sup, ChildSpec)向监督者动态添加子进程,Sup 是监督者的pid或名称,ChildSpec 是一个子规范。子进程用start_child/2来添加。注意:假如监督者死掉后重启,那么所有动态添加的子进程都不复存在

8. 停止子进程

任何静态动态添加的子进程都可以用supervisor:terminate_child(Sup, Id)来停止。一个停止子进程规范可以用supervisor:delete_child(Sup, Id)来删除。Sup是监督者的pid或名称,Id是子规范的id

9. Simple-One-For-One

监督者的simple_one_for_one启动策略是one_for_one的简版,所有子进程都是同一进程实例而被动态添加,下面是一个 simple_one_for_one监督者的实例
 
当启动时,监督者不启动任何子进程,取而代之的是所有子进程都通过调用supervisor:start_child(Sup, List)来动态添加,Sup 是监督者的pid或名称,List 是添加给子规范中指定参数列表term列表,如果启动函数是{M, F, A}这种形式,那么子进程通过调用apply(M, F, A++List)而被启动
例如,给上面的例子添加一个子进程
 
那么子进程通过调用apply(call, start_link, []++[id1])而被启动,实际上就是call:start_link(id1)

10. 停止

因为监控者是监控树的一部分,它自动被他的监督者停止,根据相应规范,它反序停止它的所有子进程,然后终止自己

erl -s make all -s c q


erl -s make all -s c q
的解释

make
A Make Utility for Erlang
The module make provides a set of functions similar to the UNIX type Make functions.
Functions

all() -> up_to_date | error
all(Options) -> up_to_date | error
  • Options = [Option]
  •  Option = noexec | load | netload | <compiler option>
This function first looks in the current working directory for a file named Emakefile (see below) specifying the set of modules to compile and the compile options to use. If no such file is found, the set of modules to compile defaults to all modules in the current working directory.
Traversing the set of modules, it then recompiles every module for which at least one of the following conditions apply:
  • there is no object file, or
  • the source file has been modified since it was last compiled, or,
  • an include file has been modified since the source file was last compiled.
As a side effect, the function prints the name of each module it tries to compile. If compilation fails for a module, the make procedure stops and error is returned.
Options is a list of make- and compiler options. The following make options exist:
  • noexec
    No execution mode. Just prints the name of each module that needs to be compiled.
  • load
    Load mode. Loads all recompiled modules.
  • netload
    Net load mode. Loads all recompiled modules an all known nodes.
All items in Options that are not make options are assumed to be compiler options and are passed as-is to compile:file/2. Options defaults to [].
c
Command Interface Module
The c module enables users to enter the short form of some commonly used commands.
Note!
These functions are are intended for interactive use in the Erlang shell only. The module prefix may be omitted.
q() -> void()
This function is shorthand for init:stop(), that is, it causes the node to stop in a controlled fashion.

另附emakefile内容样本
 

{
    [
        ‘src/*’
        ,’src/srv/*’
        ,’src/mod/*’
        ,’src/data/*’
        ,’src/lib/*’
        ,’src/lib/mysql/*’
    ]
    ,[
        debug_info
        ,{i, “inc”}
        ,{outdir, “ebin”}
    ]
}.

erlang四大behaviour之二 – gen_fsm

今天介绍erlang的一个非常重要的behaviour,就是gen_fsm-有限状态机,有限状态机的作用非常之多,比如文本解析,模式匹配、 游戏逻辑等等方面的处理都是它的强项,所以这个behaviour非常之重要

1. 有限状态机

有限状态机可以用下面这个公式来表达
 
表示的就是在S状态时如果有事件E发生,那么执行动作A后把状态调整到S’。

对于一个用gen_fsm行为实现的状态机来说,状态转变规则被写为符合如下规定的一系列Erlang函数:
StateName( Event, StateData ) ->
.. code for actions here …
{ next_state, StateName’, StateData’ }

2. 一个例子

erlang手册中用这个例子来解释的:开锁问题,有一个密码锁的门,它就可以看作一个状态机,初始状态门是锁着的,任何时候有人按一个密码键就会 产生一个事件,这个键值和前面的按键组合后与密码相比较,看是否正确,如果输入的密码顺序是对的,那么将门打开30秒,如果输入密码不完全,则等待下次按 钮按下,如果输入密码顺序是错的,则重新开始等待按键按下。

 

这些代码下面解释
 

3. 启动状态机

在上一节提到的例子里,我们使用code_lock:start_link(Code)启动gen_fsm
 

start_link调用gen_fsm:start_link/4,启动一个新的gen_fsm进程并连接。
1)第一个参数{local, code_lock}指定名字,在本地注册为code_lock
2)第二个参数code_lock是回调模块
3)第三个参数Code是传递给回调模块init函数的参数,就是密码锁的密码
4)第四个[]是状态机的选项
如果进程注册成功,则新的gen_fsm进程调用code_lock:init(Code),返回{ok, StateName, StateData}。StateName是gen_fsm的初始状态,在这里返回的是locked,表示初始状态下门是锁着的,StateData是 gen_fsm的内部状态,在这里Statedata是当前的按键顺序(初始时为空)和正确的锁代码,是个列表
 

注意gen_fsm:start_link是同步的,直到gen_fsm进程初始化并准备好开始接受请求时才会返回。加入gen_fsm是监控树的 一部分,那么gen_fsm:start_link必须被使用,也就是被一个监控者调用,gen_fsm:start则是启动单独的gen_fsm进程, 也就是gen_fsm不是监控树的一部分

4. 事件通知

使用gen_fsm:send_event/2来实现按建事件的通知
 

code_lock是gen_fsm的名字,且必须用这个名字启动进程,{button, Digit}是发送的事件,事件是作为消息发送给gen_fsm的,当事件被接收到,gen_fsm就调用StateName(Event, StateData),它的返回值应该是{next_state, StateName1, StateData1}。StateName是当前状态名称,而StateName1是将转换到的下一状态名称,StateData1是 StateData的新值
 

假如门是锁着的且按了一个按键,完整的按键序列和密码相比较,根据比较结果来决定门是打开(状态切到open)还是保持locked状态。

5 超时

假如输入的密码正确,门被打开,locked/2函数返回下面的序列
 

30000表示超时30000毫秒,在30秒后,超时发生,调用StateName(timeout, StateData) ,门又重新锁上
 

6. 所有状态事件

有时候一个事件可以到达gen_fsm进程的任何状态,取代用gen_fsm:send_event/2发送消息和写一段每个状态函数处理事件的代 码,这个消息我们可以用gen_fsm:send_all_state_event/2 发送,用Module:handle_event/3处理
 在gen_fsm的任何状态都有可能有事件到达。除了可以用gen_fsm:send_event/2发送消息,然后为每一个状态函数写一个子句来处理事件之外,还可以通过gen_fsm:send_all_state_event/2来发送消息,并通过Module:handle_event/3来处理。

1. -module(code_lock).
2. …
3. -export([stop/0]).
4. …
5. stop() ->
6. gen_fsm:send_all_state_event(code_lock, stop).
7. …
8. handle_event(stop, _StateName, StateData) ->
9. {stop, normal, StateData}.

 

7. 停止

假如gen_fsm是监控树的一部分,则不需要停止方法,gen_fsm会自动被监控者停止。如果需要在结束前清理数据,那么shutdown strategy必须为一个timeout,并且必须在gen_fsm的init方法里设置捕获exit信号,然后
gen_fsm进程会调用callback方法terminate(shutdown, StateName, StateData)
 

8. 独立gen_fsm进程

加入gen_fsm不是监控树的一部分,stop函数可能有用,如:
 
回调函数处理stop事件并返回{stop, normal, StateData1},normal表示正常停止,StateData1为gen_fsm的新的StateData值,这将导致gen_fsm调用 terminate(normal, StateName, StateData1)然后自然的停止

9. 处理其他信息

收到的其他消息由handle_info(Info, StateName, StateData)处理,其他消息的一个例子就是exit消息,假如gen_fsm进程与其他进程link了并且trace了信号,就要处理exit消 息
 

erl启动参数说明

最近被一个问题困扰,先把错误提示发出来:
kernel-poll not supported; "K" parameter ignored
{error_logger,{{2010,3,27},{9,23,16}},"Protocol: ~p: register error: ~p~n",["inet_tcp",{{badmatch,{error,duplicate_name}},[{inet_tcp_dist,listen,1},{net_kernel,start_protos,4},{net_kernel,start_protos,3},{net_kernel,init_node,2},{net_kernel,init,1},{gen_server,init_it,6},{proc_lib,init_p_do_apply,3}]}]}
{error_logger,{{2010,3,27},{9,23,16}},crash_report,[[{initial_call,{net_kernel,init,[‘Argument__1’]}},{pid,<0.20.0>},{registered_name,[]},{error_info,{exit,{error,badarg},[{gen_server,init_it,6},{proc_lib,init_p_do_apply,3}]}},{ancestors,[net_sup,kernel_sup,<0.9.0>]},{messages,[]},{links,[#Port<0.65>,<0.17.0>]},{dictionary,[{longnames,true}]},{trap_exit,true},{status,running},{heap_size,377},{stack_size,24},{reductions,454}],[]]}
{error_logger,{{2010,3,27},{9,23,16}},supervisor_report,[{supervisor,{local,net_sup}},{errorContext,start_error},{reason,{‘EXIT’,nodistribution}},{offender,[{pid,undefined},{name,net_kernel},{mfa,{net_kernel,start_link,[[‘xge@127.0.0.1’,longnames]]}},{restart_type,permanent},{shutdown,2000},{child_type,worker}]}]}
{error_logger,{{2010,3,27},{9,23,16}},supervisor_report,[{supervisor,{local,kernel_sup}},{errorContext,start_error},{reason,shutdown},{offender,[{pid,undefined},{name,net_sup},{mfa,{erl_distribution,start_link,[]}},{restart_type,permanent},{shutdown,infinity},{child_type,supervisor}]}]}
{error_logger,{{2010,3,27},{9,23,16}},std_info,[{application,kernel},{exited,{shutdown,{kernel,start,[normal,[]]}}},{type,permanent}]}
{"Kernel pid terminated",application_controller,"{application_start_failure,kernel,{shutdown,{kernel,start,[normal,[]]}}}"}

Crash dump was written to: erl_crash.dump
Kernel pid terminated (application_controller) ({application_start_failure,kernel,{shutdown,{kernel,start,[normal,[]]}}})

Crash dump was written to: erl_crash.dump
Kernel pid terminated (application_controller) ({application_start_failure,kernel,{shutdown,{kernel,start,[normal,[]]}}})

Abnormal termination

百思不得其解,接着在运行程序的bat文件上下功夫,该BAT文件的内容是:
cd ebin
start werl +P 102400 +K true +S 2 -smp -name xge@127.0.0.1 -setcookie xge -config elog -s xge start

我想启动SHELL的命令行参数有很大关系,所以参看了下DOC文档,如下,使用到的参数高亮一下。

(最后找到问题的原因在于数据库无法连接,因为创建的用户无法对未授权的数据库进行操作。可是错误太怪了,这样的错误真的不好确定出错的原因!)

erl

COMMAND
erl

 

COMMAND SUMMARY
The Erlang Emulator

 

DESCRIPTION
The erl program starts an Erlang runtime system. The exact details (for example, whether erl is a script or a program and which other programs it calls) are system-dependent.
Windows users probably wants to use the werl program instead, which runs in its own window with scrollbars and supports command-line editing. The erl program on Windows provides no line editing in its shell, and on Windows 95 there is no way to scroll back to text which has scrolled off the screen. The erl program must be used, however, in pipelines or if you want to redirect standard input or output.

 

EXPORTS
Starts an Erlang runtime system.
The arguments can be divided into emulator flags, flags and plain arguments:
  • Any argument starting with the character + is interpreted as an emulator flag.
    As indicated by the name, emulator flags controls the behavior of the emulator.
  • Any argument starting with the character – (hyphen) is interpreted as a flag which should be passed to the Erlang part of the runtime system, more specifically to the init system process, see init(3).
    The init process itself interprets some of these flags, the init flags. It also stores any remaining flags, the user flags. The latter can be retrieved by calling init:get_argument/1.
    It can be noted that there are a small number of "-" flags which now actually are emulator flags, see the description below.
  • Plain arguments are not interpreted in any way. They are also stored by the init process and can be retrieved by calling init:get_plain_arguments/0. Plain arguments can occur before the first flag, or after a — flag. Additionally, the flag -extra causes everything that follows to become plain arguments.
Example:
% erl +W w -sname arnie +R 9 -s my_init -extra +bertie
(arnie@host)1> init:get_argument(sname).
{ok,[["arnie"]]}
(arnie@host)2> init:get_plain_arguments().
["+bertie"]
Here +W w and +R 9 are emulator flags. -s my_init is an init flag, interpreted by init. -sname arnie is a user flag, stored by init. It is read by Kernel and will cause the Erlang runtime system to become distributed. Finally, everything after -extra (that is, +bertie) is considered as plain arguments.
% erl -myflag 1
1> init:get_argument(myflag).
{ok,[["1"]]}
2> init:get_plain_arguments().
[]
Here the user flag -myflag 1 is passed to and stored by the init process. It is a user defined flag, presumably used by some user defined application.

 
Flags

In the following list, init flags are marked (init flag). Unless otherwise specified, all other flags are user flags, for which the values can be retrieved by calling init:get_argument/1. Note that the list of user flags is not exhaustive, there may be additional, application specific flags which instead are documented in the corresponding application documentation.

 

–(init flag)
Everything following — up to the next flag (-flag or +flag) is considered plain arguments and can be retrieved using init:get_plain_arguments/0.
-Application Par Val
Sets the application configuration parameter Par to the value Val for the application Application, see app(4) and application(3).
-args_file FileName
Command line arguments are read from the file FileName. The arguments read from the file replace the ‘-args_file FileName’ flag on the resulting command line.
The file FileName should be a plain text file and may contain comments and command line arguments. A comment begins with a # character and continues until next end of line character. Backslash (\\) is used as quoting character. All command line arguments accepted by erl are allowed, also the -args_file FileName flag. Be careful not to cause circular dependencies between files containing the -args_file flag, though.
The -extra flag is treated specially. Its scope ends at the end of the file. Arguments following an -extra flag are moved on the command line into the -extra section, i.e. the end of the command line following after an -extra flag.
-async_shell_start
The initial Erlang shell does not read user input until the system boot procedure has been completed (Erlang 5.4 and later). This flag disables the start synchronization feature and lets the shell start in parallel with the rest of the system.
-boot File
Specifies the name of the boot file, File.boot, which is used to start the system. See init(3). Unless File contains an absolute path, the system searches for File.boot in the current and $ROOT/bin directories.
Defaults to $ROOT/bin/start.boot.
-boot_var Var Dir
If the boot script contains a path variable Var other than $ROOT, this variable is expanded to Dir. Used when applications are installed in another directory than $ROOT/lib, see systools:make_script/1,2.
-code_path_cache
Enables the code path cache of the code server, see code(3).
-compile Mod1 Mod2 …
Compiles the specified modules and then terminates (with non-zero exit code if the compilation of some file did not succeed). Implies -noinput. Not recommended – use erlc instead.
-config Config
Specifies the name of a configuration file, Config.config, which is used to configure applications. See app(4) and application(3).
-connect_all false
If this flag is present, global will not maintain a fully connected network of distributed Erlang nodes, and then global name registration cannot be used. See global(3).
-cookie Cookie
Obsolete flag without any effect and common misspelling for -setcookie. Use -setcookie instead.
-detached
Starts the Erlang runtime system detached from the system console. Useful for running daemons and backgrounds processes.
-emu_args
Useful for debugging. Prints out the actual arguments sent to the emulator.
-env Variable Value
Sets the host OS environment variable Variable to the value Value for the Erlang runtime system. Example:
% erl -env DISPLAY gin:0
In this example, an Erlang runtime system is started with the DISPLAY environment variable set to gin:0.
-eval Expr(init flag)

Makes init evaluate the expression Expr, see init(3).
-extra(init flag)

Everything following -extra is considered plain arguments and can be retrieved using init:get_plain_arguments/0.
-heart

Starts heart beat monitoring of the Erlang runtime system. See heart(3).
-hidden

Starts the Erlang runtime system as a hidden node, if it is run as a distributed node. Hidden nodes always establish hidden connections to all other nodes except for nodes in the same global group. Hidden connections are not published on either of the connected nodes, i.e. neither of the connected nodes are part of the result from nodes/0 on the other node. See also hidden global groups, global_group(3).
-hosts Hosts

Specifies the IP addresses for the hosts on which Erlang boot servers are running, see erl_boot_server(3). This flag is mandatory if the -loader inet flag is present.
The IP addresses must be given in the standard form (four decimal numbers separated by periods, for example "150.236.20.74". Hosts names are not acceptable, but a broadcast address (preferably limited to the local network) is.
-id Id

Specifies the identity of the Erlang runtime system. If it is run as a distributed node, Id must be identical to the name supplied together with the -sname or -name flag.
-init_debug

Makes init write some debug information while interpreting the boot script.
-instr(emulator flag)
Selects an instrumented Erlang runtime system (virtual machine) to run, instead of the ordinary one. When running an instrumented runtime system, some resource usage data can be obtained and analysed using the module instrument. Functionally, it behaves exactly like an ordinary Erlang runtime system.
-loader Loader

Specifies the method used by erl_prim_loader to load Erlang modules into the system. See erl_prim_loader(3). Two Loader methods are supported, efile and inet. efile means use the local file system, this is the default. inet means use a boot server on another machine, and the -id, -hosts and -setcookie flags must be specified as well. If Loader is something else, the user supplied Loader port program is started.
-make

Makes the Erlang runtime system invoke make:all() in the current working directory and then terminate. See make(3). Implies -noinput.
-man Module

Displays the manual page for the Erlang module Module. Only supported on Unix.
-mode interactive | embedded

Indicates if the system should load code dynamically (interactive), or if all code should be loaded during system initialization (embedded), see code(3). Defaults to interactive.
-name Name

Makes the Erlang runtime system into a distributed node. This flag invokes all network servers necessary for a node to become distributed. See net_kernel(3). It is also ensured that epmd runs on the current host before Erlang is started. See epmd(1).
The name of the node will be Name@Host, where Host is the fully qualified host name of the current host. For short names, use the -sname flag instead.
-noinput

Ensures that the Erlang runtime system never tries to read any input. Implies -noshell.
-noshell

Starts an Erlang runtime system with no shell. This flag makes it possible to have the Erlang runtime system as a component in a series of UNIX pipes.
-nostick

Disables the sticky directory facility of the Erlang code server, see code(3).
-oldshell

Invokes the old Erlang shell from Erlang 3.3. The old shell can still be used.
-pa Dir1 Dir2 …

Adds the specified directories to the beginning of the code path, similar to code:add_pathsa/1. See code(3). As an alternative to -pa, if several directories are to be prepended to the code and the directories have a common parent directory, that parent directory could be specified in the ERL_LIBS environment variable. See code(3).
-pz Dir1 Dir2 …

Adds the specified directories to the end of the code path, similar to code:add_pathsz/1. See code(3).
-remsh Node

Starts Erlang with a remote shell connected to Node.
-rsh Program

Specifies an alternative to rsh for starting a slave node on a remote host. See slave(3).
-run Mod [Func [Arg1, Arg2, …]](init flag)

Makes init call the specified function. Func defaults to start. If no arguments are provided, the function is assumed to be of arity 0. Otherwise it is assumed to be of arity 1, taking the list [Arg1,Arg2,…] as argument. All arguments are passed as strings. See init(3).
-s Mod [Func [Arg1, Arg2, …]](init flag)

Makes init call the specified function. Func defaults to start. If no arguments are provided, the function is assumed to be of arity 0. Otherwise it is assumed to be of arity 1, taking the list [Arg1,Arg2,…] as argument. All arguments are passed as atoms. See init(3).
-setcookie Cookie

Sets the magic cookie of the node to Cookie, see erlang:set_cookie/2.
-shutdown_time Time

Specifies how long time (in milliseconds) the init process is allowed to spend shutting down the system. If Time ms have elapsed, all processes still existing are killed. Defaults to infinity.
-sname Name

Makes the Erlang runtime system into a distributed node, similar to -name, but the host name portion of the node name Name@Host will be the short name, not fully qualified.
This is sometimes the only way to run distributed Erlang if the DNS (Domain Name System) is not running. There can be no communication between nodes running with the -sname flag and those running with the -name flag, as node names must be unique in distributed Erlang systems.
-smp [enable|auto|disable]
-smp enable and -smp starts the Erlang runtime system with SMP support enabled. This may fail if no runtime system with SMP support is available. -smp auto starts the Erlang runtime system with SMP support enabled if it is available and more than one logical processor are detected. -smp disable starts a runtime system without SMP support. By default -smp auto will be used unless a conflicting parameter has been passed, then -smp disable will be used. Currently only the -hybrid parameter conflicts with -smp auto.
NOTE: The runtime system with SMP support will not be available on all supported platforms. See also the +S flag.
-version(emulator flag)
Makes the emulator print out its version number. The same as erl +V.

 

Emulator Flags

erl invokes the code for the Erlang emulator (virtual machine), which supports the following flags:
+a size
Suggested stack size, in kilowords, for threads in the async-thread pool. Valid range is 16-8192 kilowords. The default suggested stack size is 16 kilowords, i.e, 64 kilobyte on 32-bit architectures. This small default size has been chosen since the amount of async-threads might be quite large. The default size is enough for drivers delivered with Erlang/OTP, but might not be sufficiently large for other dynamically linked in drivers that use the driver_async() functionality. Note that the value passed is only a suggestion, and it might even be ignored on some platforms.
+A size
Sets the number of threads in async thread pool, valid range is 0-1024. Default is 0.
+B [c | d | i]
The c option makes Ctrl-C interrupt the current shell instead of invoking the emulator break handler. The d option (same as specifying +B without an extra option) disables the break handler. The i option makes the emulator ignore any break signal.
If the c option is used with oldshell on Unix, Ctrl-C will restart the shell process rather than interrupt it.
Note that on Windows, this flag is only applicable for werl, not erl (oldshell). Note also that Ctrl-Break is used instead of Ctrl-C on Windows.
+c
Disable compensation for sudden changes of system time.
Normally, erlang:now/0 will not immediately reflect sudden changes in the system time, in order to keep timers (including receive-after) working. Instead, the time maintained by erlang:now/0 is slowly adjusted towards the new system time. (Slowly means in one percent adjustments; if the time is off by one minute, the time will be adjusted in 100 minutes.)
When the +c option is given, this slow adjustment will not take place. Instead erlang:now/0 will always reflect the current system time. Note that timers are based on erlang:now/0. If the system time jumps, timers then time out at the wrong time.
+d
If the emulator detects an internal error (or runs out of memory), it will by default generate both a crash dump and a core dump. The core dump will, however, not be very useful since the content of process heaps is destroyed by the crash dump generation.
The +d option instructs the emulator to only produce a core dump and no crash dump if an internal error is detected.
Calling erlang:halt/1 with a string argument will still produce a crash dump.
+hms Size
Sets the default heap size of processes to the size Size.
+hmbs Size
Sets the default binary virtual heap size of processes to the size Size.
+K true | false
Enables or disables the kernel poll functionality if the emulator supports it. Default is false (disabled). If the emulator does not support kernel poll, and the +K flag is passed to the emulator, a warning is issued at startup.
+l
Enables auto load tracing, displaying info while loading code.
+MFlag Value
Memory allocator specific flags, see erts_alloc(3) for further information.
+P Number
Sets the maximum number of concurrent processes for this system. Number must be in the range 16..134217727. Default is 32768.
+R ReleaseNumber
Sets the compatibility mode.
The distribution mechanism is not backwards compatible by default. This flags sets the emulator in compatibility mode with an earlier Erlang/OTP release ReleaseNumber. The release number must be in the range 7..<current release>. This limits the emulator, making it possible for it to communicate with Erlang nodes (as well as C- and Java nodes) running that earlier release.
For example, an R10 node is not automatically compatible with an R9 node, but R10 nodes started with the +R 9 flag can co-exist with R9 nodes in the same distributed Erlang system, they are R9-compatible.
Note: Make sure all nodes (Erlang-, C-, and Java nodes) of a distributed Erlang system is of the same Erlang/OTP release, or from two different Erlang/OTP releases X and Y, where all Y nodes have compatibility mode X.
For example: A distributed Erlang system can consist of R10 nodes, or of R9 nodes and R9-compatible R10 nodes, but not of R9 nodes, R9-compatible R10 nodes and "regular" R10 nodes, as R9 and "regular" R10 nodes are not compatible.
+r
Force ets memory block to be moved on realloc.
+S Schedulers:SchedulerOnline
Sets the amount of scheduler threads to create and scheduler threads to set online when SMP support has been enabled. Valid range for both values are 1-1024. If the Erlang runtime system is able to determine the amount of logical processors configured and logical processors available, Schedulers will default to logical processors configured, and SchedulersOnline will default to logical processors available; otherwise, the default values will be 1. Schedulers may be omitted if :SchedulerOnline is not and vice versa. The amount of schedulers online can be changed at run time via erlang:system_flag(schedulers_online, SchedulersOnline).
This flag will be ignored if the emulator doesn’t have SMP support enabled (see the -smp flag).
+sFlag Value
Scheduling specific flags.
+sbt BindType
Set scheduler bind type. Currently valid BindTypes:
u
ns
ts
ps
s
nnts
nnps
tnnps
db
Binding of schedulers are currently only supported on newer Linux and Solaris systems.
If no CPU topology is available when the +sbt flag is processed and BindType is any other type than u, the runtime system will fail to start. CPU topology can be defined using the +sct flag. Note that the +sct flag may have to be passed before the +sbt flag on the command line (in case no CPU topology has been automatically detected).
+sct CpuTopology
  • <Id> = integer(); when 0 =< <Id> =< 65535
  • <IdRange> = <Id>-<Id>
  • <IdOrIdRange> = <Id> | <IdRange>
  • <IdList> = <IdOrIdRange>,<IdOrIdRange> | <IdOrIdRange>
  • <LogicalIds> = L<IdList>
  • <ThreadIds> = T<IdList> | t<IdList>
  • <CoreIds> = C<IdList> | c<IdList>
  • <ProcessorIds> = P<IdList> | p<IdList>
  • <NodeIds> = N<IdList> | n<IdList>
  • <IdDefs> = <LogicalIds><ThreadIds><CoreIds><ProcessorIds><NodeIds> | <LogicalIds><ThreadIds><CoreIds><NodeIds><ProcessorIds>
  • CpuTopology = <IdDefs>:<IdDefs> | <IdDefs>
Upper-case letters signify real identifiers and lower-case letters signify fake identifiers only used for description of the topology. Identifiers passed as real identifiers may be used by the runtime system when trying to access specific hardware and if they are not correct the behavior is undefined. Faked logical CPU identifiers are not accepted since there is no point in defining the CPU topology without real logical CPU identifiers. Thread, core, processor, and node identifiers may be left out. If left out, thread id defaults to t0, core id defaults to c0, processor id defaults to p0, and node id will be left undefined. Either each logical processor must belong to one and only one NUMA node, or no logical processors must belong to any NUMA nodes.
Both increasing and decreasing <IdRange>s are allowed.
NUMA node identifiers are system wide. That is, each NUMA node on the system have to have a unique identifier. Processor identifiers are also system wide. Core identifiers are processor wide. Thread identifiers are core wide.
The order of the identifier types imply the hierarchy of the CPU topology. Valid orders are either <LogicalIds><ThreadIds><CoreIds><ProcessorIds><NodeIds>, or <LogicalIds><ThreadIds><CoreIds><NodeIds><ProcessorIds>. That is, thread is part of a core which is part of a processor which is part of a NUMA node, or thread is part of a core which is part of a NUMA node which is part of a processor. A cpu topology can consist of both processor external, and processor internal NUMA nodes as long as each logical processor belongs to one and only one NUMA node. If <ProcessorIds> is left out, its default position will be before <NodeIds>. That is, the default is processor external NUMA nodes.
If a list of identifiers is used in an <IdDefs>:
  • <LogicalIds> have to be a list of identifiers.
  • At least one other identifier type apart from <LogicalIds> also have to have a list of identifiers.
  • All lists of identifiers have to produce the same amount of identifiers.
A simple example. A single quad core processor may be described this way:
% erl +sct L0-3c0-3
1> erlang:system_info(cpu_topology).
[{processor,[{core,{logical,0}},
{core,{logical,1}},
{core,{logical,2}},
{core,{logical,3}}]}]
A little more complicated example. Two quad core processors. Each processor in its own NUMA node. The ordering of logical processors is a little weird. This in order to give a better example of identifier lists:
% erl +sct L0-1,3-2c0-3p0N0:L7,4,6-5c0-3p1N1
1> erlang:system_info(cpu_topology).
[{node,[{processor,[{core,{logical,0}},
{core,{logical,1}},
{core,{logical,3}},
{core,{logical,2}}]}]},
{node,[{processor,[{core,{logical,7}},
{core,{logical,4}},
{core,{logical,6}},
{core,{logical,5}}]}]}]
As long as real identifiers are correct it is okay to pass a CPU topology that is not a correct description of the CPU topology. When used with care this can actually be very useful. This in order to trick the emulator to bind its schedulers as you want. For example, if you want to run multiple Erlang runtime systems on the same machine, you want to reduce the amount of schedulers used and manipulate the CPU topology so that they bind to different logical CPUs. An example, with two Erlang runtime systems on a quad core machine:
% erl +sct L0-3c0-3 +sbt db +S3:2 -detached -noinput -noshell -sname one
% erl +sct L3-0c0-3 +sbt db +S3:2 -detached -noinput -noshell -sname two
In this example each runtime system have two schedulers each online, and all schedulers online will run on different cores. If we change to one scheduler online on one runtime system, and three schedulers online on the other, all schedulers online will still run on different cores.
Note that a faked CPU topology that does not reflect how the real CPU topology looks like is likely to decrease the performance of the runtime system.
+sss size
Suggested stack size, in kilowords, for scheduler threads. Valid range is 4-8192 kilowords. The default stack size is OS dependent.
+t size
Set the maximum number of atoms the VM can handle. Default is 1048576.
+T Level
Enables modified timing and sets the modified timing level. Currently valid range is 0-9. The timing of the runtime system will change. A high level usually means a greater change than a low level. Changing the timing can be very useful for finding timing related bugs.
Currently, modified timing affects the following:
Process spawning
A process calling spawn, spawn_link, spawn_monitor, or spawn_opt will be scheduled out immediately after completing the call. When higher modified timing levels are used, the caller will also sleep for a while after being scheduled out.
Context reductions
The amount of reductions a process is a allowed to use before being scheduled out is increased or reduced.
Input reductions
The amount of reductions performed before checking I/O is increased or reduced.
NOTE: Performance will suffer when modified timing is enabled. This flag is only intended for testing and debugging. Also note that return_to and return_from trace messages will be lost when tracing on the spawn BIFs. This flag may be removed or changed at any time without prior notice.
+V
Makes the emulator print out its version number.
+v
Verbose.
+W w | i
Sets the mapping of warning messages for error_logger. Messages sent to the error logger using one of the warning routines can be mapped either to errors (default), warnings (+W w), or info reports (+W i). The current mapping can be retrieved using error_logger:warning_map/0. See error_logger(3) for further information.

 

ERL_CRASH_DUMP
If the emulator needs to write a crash dump, the value of this variable will be the file name of the crash dump file. If the variable is not set, the name of the crash dump file will be erl_crash.dump in the current directory.
ERL_CRASH_DUMP_NICE
Unix systems: If the emulator needs to write a crash dump, it will use the value of this variable to set the nice value for the process, thus lowering its priority. The allowable range is 1 through 39 (higher values will be replaced with 39). The highest value, 39, will give the process the lowest priority.
ERL_CRASH_DUMP_SECONDS
Unix systems: This variable gives the number of seconds that the emulator will be allowed to spend writing a crash dump. When the given number of seconds have elapsed, the emulator will be terminated by a SIGALRM signal.
ERL_AFLAGS
The content of this environment variable will be added to the beginning of the command line for erl.
The -extra flag is treated specially. Its scope ends at the end of the environment variable content. Arguments following an -extra flag are moved on the command line into the -extra section, i.e. the end of the command line following after an -extra flag.
ERL_ZFLAGSand ERL_FLAGS
The content of these environment variables will be added to the end of the command line for erl.
The -extra flag is treated specially. Its scope ends at the end of the environment variable content. Arguments following an -extra flag are moved on the command line into the -extra section, i.e. the end of the command line following after an -extra flag.
ERL_LIBS
This environment variable contains a list of additional library directories that the code server will search for applications and add to the code path. See code(3).
ERL_EPMD_PORT
This environment variable can contain the port number to use when communicating with epmd. The default port will work fine in most cases. A different port can be specified to allow nodes of independent clusters to co-exist on the same host. All nodes in a cluster must use the same epmd port number.

 

init(3), erl_prim_loader(3), erl_boot_server(3), code(3), application(3), heart(3), net_kernel(3), auth(3), make(3), epmd(1), erts_alloc(3)

此外对一些参数作下说明:

-name node@host
指定节点的名称,在其它机器上运行的节点就可以访问它

-sname node
指定一个本地节点,在同一台机器上的其它节点可以访问它

-setcookie xx22yyz
指定认证有的cookie,相互通信的节点必须使用同样的cookie

-noshell
非交互方式运行,如果不加这个参数,就会 交互式运行。加上它之后,就可以加入到shell中,开
机运行

-detached
在后台运行。适合于daemon程序。

-noinput
不 读取任何输入

-pa Dir1 Dir2 …
将Dir1 Dir2加到codepath之前,这样加载代码时就先搜索这些目录

-pz Dir1 Dir2 …
将 Dir1 Dir2加到codepath之后,这样最后加载代码时最后搜索这些目录

-run Mod [Func [Arg1, Arg2, …]]
-s Mod [Func [Arg1, Arg2, …]]
运后Mod:Fun

-smp enable
+S Number
启用smp,并运行Number个虚拟机,可以大于实际CPU的个数