A simple Erlang process pool Analysis

A simple Erlang process pool Analysis

This is a simple Erlang process pool analysis, which islearn you some erlang for Great GoodHere is an example. For details, go to the official website!

Main Flowchart

Implementation Principle

The implementation principles of this example are described in detail on the official website.ppool_servMedium,ppool_servIsgen_server behaviour, Andppool_supIsone_for_allPolicy, ifppool_servOrworker_supThere is no need for problems to exist with each other.

Here, the implementation of ppool_serv and worker_sup uses a simple technique, because worker_sup is not generated directly by ppool_sup, which is generated by ppool_serv control:

%% Gen serverinit({Limit, MFA, Sup}) ->    %% We need to find the Pid of the worker supervisor from here,    %% but alas, this would be calling the supervisor while it waits for us!    self() ! {start_worker_supervisor, Sup, MFA},    {ok, #state{limit=Limit, refs=gb_sets:empty()}}.

woker_supByppool_servIninitFunction, send a message to yourself, and then generate in the callback function:

handle_info({start_worker_supervisor, Sup, MFA}, S = #state{}) ->    {ok, Pid} = supervisor:start_child(Sup, ?SPEC(MFA)),    link(Pid),    {noreply, S#state{sup=Pid}};

If they are directly produced together, a deadlock will occur,

Of course, you can modify the generation sequence here without deadlock.

Main data structure of gen_serv

-define(SPEC(MFA),        {worker_sup,         {ppool_worker_sup, start_link, [MFA]},          temporary,          10000,          supervisor,          [ppool_worker_sup]}).-record(state, {limit=0,                sup,                refs,                queue=queue:new()}).

?SPEC(MFA), HereMFAClass 1Task, So the sameppool_worker_sup, There will be no different types of tasks, and its policy is alsosimple_one_for_one.

In this example, a gen_server -- nnager module is used as the task. The parameters of this task are {task, delay, Max, sendto}, which indicates the task name, as the timeout time, delay only indicates that the task has a timeout limit. It is also a debugging technique. Max indicates the maximum number of timeouts. sendto is used to send messages to the callback process. This process can be a shell, if it is shell, flush () will receive the message.

recordIt is used to identify some major information. limit is the size limit of the Process pool. Sup starts to be the PID () of ppool_sup. After the woker_sup process is generated, it becomes the process PID () of worker_sup (), because ppool_serv's main communication objects are worker_sup and worker (task); refs (gb_set) is the link of woker processes, so that when the worker process is down or done, remove from the thread pool; the queue is the task queue. When the task is larger than the limit, the redundant tasks are placed in the queque. When the process pool is idle, the tasks are pop out, proceed.

Some limitations: 1. each task is processed by a new process. That is to say, the lifecycle of the process is the same as that of the task. You can separate the process from the task, let the process not end with the end of the task (of course, this task is not about gen_server, gen_fsm, because these are also spawn processes), so that the process overhead can be initialized theoretically once, although the process is sold less in Erlang, 2. no queue size limit