A simple Erlang process pool analysis

A simple Erlang process pool analysis

This is a simple Erlang process pool analysis, is learn you some erlang for Great Good a example inside, the specific content can be viewed on the official website!

Basic flowchart

Implementation principle

This example of the implementation of the principle of the official website has a specific description, the main module inppool_servInppool_servis agen_server behaviour, whileppool_supis aone_for_allThe strategy, assuming thatppool_servOrworker_supThere is no need for each other to be in trouble.

Here Ppool_serv and Worker_sup implementations, using a simple technique, because worker_sup is not generated by the Ppool_sup direct call, it is generated by the Ppool_serv control:

Percent of Gen serverInit({Limit, MFA, Sup})  -    Percent We need to find the Pid of the worker supervisor from here,    Percent Alas, this would is calling the supervisor while it waits for us!     Self() ! {Start_worker_supervisor, Sup, MFA},    {OK, #state{Limit=Limit, Refs=gb_sets:Empty()}}.

woker_supBy ppool_serv yourself in the init function, send yourself a message and then generate it 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}};

Assuming that they produce together directly, there is a deadlock,

Of course, the order of his generation here can be changed by himself, and there will be no 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), the MFA specified class here, Task so the same ppool_worker_sup , there will not be different types of task, its strategy is also simple_one_for_one .

In this example, a Gen_server-Nnager module is used as a task, the task has the following parameters: {task, delay, Max, SendTo}, Task name, delay as time-out, Just marking this task with a timeout limit is also a debugging technique, Max is the maximum timeout, sendto is used to send information to the callback process, the process can be the shell, assuming that Shell,flush () will receive the message.

recordUsed to identify some basic information, limit is the size of the process pool, the SUP starts as Ppool_sup pid (), after generating the woker_sup process, it becomes the worker_sup process PID (), because Ppool_ Serv's primary communication object is Worker_sup and worker (Task), and refs (Gb_set) is a woker process link that can be removed from the thread pool when the worker process is down or done, and the queue is the task When the task is greater than limit, the redundant task is put into the queque, and when the process pool has spare, it pops out of the task and then processes it.

Here are some limitations : 1. Each task is a new process to deal with, that is, the life cycle of the process is the same as the life cycle of the task, able to separate the process from the task, so that the process does not end with the end of the task (of course, the task is not gen_server, Gen_fsm These, because these are also spawn out of the process), so that the process overhead is theoretically initialized, although the process in Erlang overhead is relatively small; 2. Queue has no limit size

A simple Erlang process pool analysis