7. Application

This chapter correspondsAPP (4)AndApplication (3).

Application concepts

After we write code that implements specific functions, we may want to convert the code intoApplication(Application), which can be started and stopped as a unit, and can be reused in other systems.

Create an application callback module, which describes how the application should be started and stopped.

Then, you needApplication SpecificationIt is placed in an application resource file. We also specify the modules that the application consists of and the names of each callback module.

If we usesystools-- Erlang/OTP code for packaging (seeRelease), The Code of each application can be placed in a separate directory according to the predefined directory structure.

Application callback Module

The following two return functions describe how to start and stop the application code, namely the supervision tree:

start(StartType, StartArgs) -> {ok, Pid} | {ok, Pid, State}stop(State)

When you want to create a supervisor tree by starting the top-level supervisorstart. It returns the PID of the top-level governor and an option value.StateThe default value is []. This value is passedstop.

StartTypeUsually atomicnormal. Other values are available only during take-over or failover. For more information, seeDistributed Application.StartArgsBy the key in the Application resource filemod.

When the application is stoppedAfterYesstop/1. Note that the actual stop process of the application, that is, the shutdown of the supervision tree, is automatically handled according to the method described in start and stop the application.

The following is an example fromDu ChengThe process in Chapter 1 is packaged as an application callback module:

-module(ch_app).-behaviour(application).-export([start/2, stop/1]).start(_Type, _Args) ->    ch_sup:start_link().stop(_State) ->    ok.

A library Application -- cannot be started or stopped -- requires no application callback module.

Application resource file

By creatingApplication resource file-- Abbreviation.appFile -- inApplication SpecificationTo define an application:

{application, Application, [Opt1,...,OptN]}.

ApplicationIs an atom that represents the name of an application. The file must be namedApplication.app.

EveryOptAre all tuples that define certain features of an application.{Key, Value}. All keys are optional. The ignored key uses the default value.

For examplelibappOf.appFile Content:

{application, libapp, []}.

For imagesch_appMinimize the number of such supervised tree applications.appFile Content:

{application, ch_app, [{mod, {ch_app,[]}}]}.

KeymodThe callback module and startup parameters of the application are defined.ch_appAnd []. This indicates that the application is called at startup:

ch_app:start(normal, [])

When the application is stopped, it will call:

ch_app:stop([])

When usingsystoolsErlang/OTP tool packaging code (seeRelease), Keydescription,vsn,modules,registeredAndapplicationsIt should be specified:

{application, ch_app, [{description, "Channel allocator"},  {vsn, "1"},  {modules, [ch_app, ch_sup, ch3]},  {registered, [ch3]},  {applications, [kernel, stdlib, sasl]},  {mod, {ch_app,[]}} ]}.

description

Brief description, String. The default value is "".

vsn

Version number, String. The default value is "".

modules

By this application IntroductionAll modules. When the startup script and tar file are generated, systoolsThis list will be used. A module must be defined and only applicable to one application. The default value is [].

registered

Name of all registration processes in the application. systoolsUse this list to detect whether there is a name conflict between applications. The default value is [].

applications

All applications that must be started before this application. systoolsUse this list to generate the correct STARTUP script. The default value is [], but note that any application must depend on at least kernelAnd stdlib.

The syntax and content of the application resource file are described inapp(4)Has a detailed description.

Directory structure

When usingsystoolsWhen code is packaged, the code of each application is stored in a separate directory.lib/Application-Vsn, WhereVsnIs the version number.

Even ifsystools, It is best to know about it, because Erlang/OTP itself is packaged according to the OTP principle, so this directory structure is available. If multiple versions of an application exist, the Code server (seecode(3)Will automatically use the code with the highest version number from the directory.

The application directory structure can also be used in the development environment. The version number can be ignored.

The application directory has the following sub-directories:

• src
• ebin
• priv
• include

src

Contains Erlang source code

ebin

Contains the Erlang target code -- beamFile. .appThe file is also placed here.

priv

Used to apply exclusive files. For example, put the C execution program here. Functions should be used code:priv_dir/1To access this directory.

include

Used to include files.

Application Controller

When Erlang is started, some processes used as the kernel application will be started. One of the processes isApplication ControllerProcess, registeredapplication_controller.

All operations on the application are coordinated by the application controller. It passes through the moduleapplicationTo expose the interface, seeapplication(3). In particular, applications can be loaded, uninstalled, started, and stopped.

Load and uninstall applications

Before starting an application, it must beLoad. The application controller reads.appThe information in.

1> application:load(ch_app).ok2> application:loaded_applications().[{kernel,"ERTS  CXC 138 10","2.8.1.3"}, {stdlib,"ERTS  CXC 138 10","1.11.4.3"}, {ch_app,"Channel allocator","1"}]

Applications that have been stopped or never started can be uninstalled. Information about the application is deleted from the internal database of the application controller.

3> application:unload(ch_app).ok4> application:loaded_applications().[{kernel,"ERTS  CXC 138 10","2.8.1.3"}, {stdlib,"ERTS  CXC 138 10","1.11.4.3"}]

Note

 

Loading/detaching an application does not load/detach the code used by the application. Code loading is generally performed.

Start and Stop an application

To start an application, call:

5> application:start(ch_app).ok6> application:which_applications().[{kernel,"ERTS  CXC 138 10","2.8.1.3"}, {stdlib,"ERTS  CXC 138 10","1.11.4.3"}, {ch_app,"Channel allocator","1"}]

If the application has not been loaded, the application controller first usesapplication:load/1Load it. It will checkapplicationsKey to make sure that all applications started before the application runs.

Then the application controller createsApplication main program. It is the leader of all processes in the application. The application main program calls the callback function in the application module.start/2Start the application..appFilemodCreate a defined startup parameter ).

Stop an application but do not uninstall it. You can call this function:

7> application:stop(ch_app).ok

Configure Application

AvailableConfiguration parametersTo configure the application. They are.appFile is a forward keyenvThe specified{Par, Val}List of tuples.

{application, ch_app, [{description, "Channel allocator"},  {vsn, "1"},  {modules, [ch_app, ch_sup, ch3]},  {registered, [ch3]},  {applications, [kernel, stdlib, sasl]},  {mod, {ch_app,[]}},  {env, [{file, "/usr/local/log"}]} ]}.

ParIt must be an atom,ValIt can be any value. Applications can callapplication:get_env(App, Par)Or some other similar functions to obtain the value of configuration parameters, seeapplication(3).

For example:

% erlErlang (BEAM) emulator version 5.2.3.6 [hipe] [threads:0]Eshell V5.2.3.6  (abort with ^G)1> application:start(ch_app).ok2> application:get_env(ch_app, file).{ok,"/usr/local/log"}

.appThe value in the file can beSystem Configuration FileThe value in. The system configuration file contains the configuration parameters of related applications.

[{Application1, [{Par11,Val11},...]}, ..., {ApplicationN, [{ParN1,ValN1},...]}].

System Configuration to be namedName.configUse command line parameters-config NameTo start Erlang. For more information, seeconfig(4).

For example, create a filetest.configIncludes the following content:

[{ch_app, [{file, "testlog"}]}].

fileWill overwrite.appThefileValue:

% erl -config testErlang (BEAM) emulator version 5.2.3.6 [hipe] [threads:0]Eshell V5.2.3.6  (abort with ^G)1> application:start(ch_app).ok2> application:get_env(ch_app, file).{ok,"testlog"}

IfRelease ProcessingOnly one system configuration file can be used.sys.config.

In.appValues in the file, including values in the system configuration file, can be overwritten directly in the command line:

% erl -ApplName Par1 Val1 ... ParN ValN

For example:

% erl -ch_app file ‘"testlog"‘Erlang (BEAM) emulator version 5.2.3.6 [hipe] [threads:0]Eshell V5.2.3.6  (abort with ^G)1> application:start(ch_app).ok2> application:get_env(ch_app, file).{ok,"testlog"}

Application Startup Type

DefineStartup Type.

application:start(Application, Type)

application:start(Application)And callapplication:start(Application, temporary)Is the same. Type can also bepermanentPersistent ortransientTransitional:

• If a persistent application is terminated, all other applications and runtime systems will be terminated.
• If a transitional application usesnormalIf the reason is terminated, this information will be reported but other applications will not be terminated. If a transitional application is terminated unexpectedlynormal-Other applications and runtime environments will also be terminated.
• If a temporary (temporary) application is terminated, the information will be reported but other applications will not be terminated.

We can always callapplication:stop/1To stop an application. No matter what the mode is, it will not affect other applications.

Note that the transition mode is rarely used in practice, because when a supervision tree is terminated, the reason for exiting is setshutdown, Rathernormal.

7. Application