0Pricing
Erlang OTP: Distributed & Fault-Tolerant Systems Programming · レッスン

動的なプロセス管理

Supervisor内で子プロセスを動的に起動・停止する方法を習得し、適応性とリソース効率に優れたシステムを実現します。

「動的なプロセス管理」はCoddyKit上の無料Erlang OTP: Distributed & Fault-Tolerant Systems Programmingレッスンです。 これはレッスン2/4です。 下記で完全なレッスンを無料で読むことができます。その後、ブラウザ内の組み込みコードエディタと24時間対応のAIチューターでハンズオン演習できます。 これはErlang OTP: Distributed & Fault-Tolerant Systems Programming学習パスの一部であり、ウェブとCoddyKitアプリ全体で進捗が同期されます。 Erlang OTP: Distributed & Fault-Tolerant Systems Programmingコースには全4レッスンが含まれています。

このレッスンの一部はまだ翻訳されておらず、英語で表示されています。

Dynamic Processes Overview

In Erlang, not all processes need to be started when your application first boots. Sometimes, you need processes that are created and destroyed on demand.

These are called dynamic processes, and they are crucial for building adaptable and resource-efficient systems. Think of them as temporary workers that supervisors can hire and fire as needed.

Why Dynamic Management?

Dynamic process management offers several key advantages:

  • Resource Efficiency: Only start processes when they are actually needed, saving memory and CPU.
  • Adaptability: Respond to varying loads by scaling up or down the number of workers.
  • On-Demand Tasks: Ideal for handling transient tasks like a new client connection, a file conversion request, or a single database query.

This contrasts with static children, which are always part of the supervisor's initial setup.

The `simple_one_for_one` Strategy

To manage dynamic children, supervisors often employ the simple_one_for_one restart strategy. This strategy is specifically designed for supervisors that will dynamically add children after startup.

  • It allows you to add children without pre-defining them in the supervisor's init/1 function.
  • Each dynamically added child is treated as a unique entity, even if they share the same underlying module.
  • If a dynamic child crashes, simple_one_for_one will restart only that child, not all of them.

Starting Dynamic Children

You start a dynamic child process using the supervisor:start_child/2 function. It takes two arguments:

  • SupRef: The name or PID of the supervisor.
  • ChildSpec: A map (or a list of tuples in older Erlang) describing the child process.

This function returns {ok, ChildPid} or an error if the child couldn't be started.

Dynamic Child Specification

A ChildSpec for a dynamic child is similar to a static one, but the id field is crucial for distinguishing instances. Here's a typical structure:

  • id: A unique atom or term to identify this specific child instance (e.g., client_123).
  • start: A tuple {Module, Function, Args} to call for starting the child (e.g., {gen_server, start_link, [{local, TaskId}, ?MODULE, [], []]}).
  • type: Either worker or supervisor.
  • restart: Often transient for dynamic workers, meaning they only restart if they crash unexpectedly, not if they exit normally.
  • shutdown: Timeout for graceful shutdown.

Code: Create Dynamic Workers

This example shows a supervisor starting two unique 'task' processes dynamically. Each task maintains its own count.

Run it to see how new processes are spawned and how you can interact with them individually.

-module(dynamic_start_example).
-behaviour(supervisor).

-export([start_link/0, init/1, start_task/1, call_task/2, run/0]).
-export([task_init/1, task_handle_call/3, task_terminate/2]).

% --- Supervisor part ---
start_link() ->
    supervisor:start_link({local, ?MODULE}, ?MODULE, []).

init([]) ->
    Strategy = {simple_one_for_one, 0, 1},
    Children = [],
    {ok, {Strategy, Children}}.

start_task(TaskId) ->
    io:format("Supervisor: Starting task ~p~n", [TaskId]),
    ChildSpec = #{
        id => TaskId,
        start => {gen_server, start_link, [{local, TaskId}, ?MODULE, [], []]},
        type => worker,
        restart => transient,
        shutdown => 5000
    },
    supervisor:start_child(?MODULE, ChildSpec).

call_task(TaskId, Message) ->
    gen_server:call(TaskId, Message).

% --- Worker part (this module acts as a gen_server for the tasks) ---
task_init([]) ->
    io:format("Task ~p: Initializing with count 0~n", [self()]),
    {ok, 0}. % Initial state for the task

task_handle_call(get_count, _From, State) ->
    io:format("Task ~p: Getting count ~p~n", [self(), State]),
    {reply, State, State}.
task_handle_call({increment, Value}, _From, State) ->
    NewState = State + Value,
    io:format("Task ~p: Incrementing by ~p to ~p~n", [self(), Value, NewState]),
    {reply, NewState, NewState}.

task_terminate(_Reason, State) ->
    io:format("Task ~p: Terminating with final state ~p~n", [self(), State]),
    ok.

% --- Entry point for runnable example ---
run() ->
    io:format("~n--- Starting Dynamic Task Example ---~n"),
    {ok, SupPid} = dynamic_start_example:start_link(),
    io:format("Supervisor started: ~p~n", [SupPid]),

    io:format("~nStarting Task 'task_alpha':~n"),
    dynamic_start_example:start_task(task_alpha),
    timer:sleep(100), % Give it a moment to start

    Count1 = dynamic_start_example:call_task(task_alpha, get_count),
    io:format("Task 'task_alpha' count: ~p~n", [Count1]),

    dynamic_start_example:call_task(task_alpha, {increment, 7}),
    Count2 = dynamic_start_example:call_task(task_alpha, get_count),
    io:format("Task 'task_alpha' count after increment: ~p~n", [Count2]),

    io:format("~nStarting Task 'task_beta':~n"),
    dynamic_start_example:start_task(task_beta),
    timer:sleep(100),

    Count3 = dynamic_start_example:call_task(task_beta, get_count),
    io:format("Task 'task_beta' count: ~p~n", [Count3]),

    dynamic_start_example:call_task(task_beta, {increment, 12}),
    Count4 = dynamic_start_example:call_task(task_beta, get_count),
    io:format("Task 'task_beta' count after increment: ~p~n", [Count4]),

    % In a real app, you'd stop the supervisor or individual tasks here.
    % For this example, we'll let them run.
    io:format("--- Dynamic Task Start Demo Finished ---~n"),
    ok.

Terminating Dynamic Children

Just as you can start processes dynamically, you can also stop them. The supervisor:terminate_child/2 function is used for this.

  • It takes the SupRef and the ChildId (the id from the child specification) as arguments.
  • The supervisor will send an exit signal to the child, initiating a graceful shutdown.
  • Once terminated, the child is removed from the supervisor's list, freeing up resources.

This is crucial for managing resources and ensuring processes don't linger unnecessarily.

Code: Terminate Dynamic Workers

This example demonstrates starting a task, interacting with it, and then gracefully stopping it using terminate_child/2. Notice the output when the task terminates.

-module(dynamic_stop_example).
-behaviour(supervisor).

-export([start_link/0, init/1, start_task/1, call_task/2, stop_task/1, run/0]).
-export([task_init/1, task_handle_call/3, task_terminate/2]).

% --- Supervisor part ---
start_link() ->
    supervisor:start_link({local, ?MODULE}, ?MODULE, []).

init([]) ->
    Strategy = {simple_one_for_one, 0, 1},
    Children = [],
    {ok, {Strategy, Children}}.

start_task(TaskId) ->
    io:format("Supervisor: Starting task ~p~n", [TaskId]),
    ChildSpec = #{
        id => TaskId,
        start => {gen_server, start_link, [{local, TaskId}, ?MODULE, [], []]},
        type => worker,
        restart => transient,
        shutdown => 5000
    },
    supervisor:start_child(?MODULE, ChildSpec).

call_task(TaskId, Message) ->
    gen_server:call(TaskId, Message).

stop_task(TaskId) ->
    io:format("Supervisor: Stopping task ~p~n", [TaskId]),
    supervisor:terminate_child(?MODULE, TaskId).

% --- Worker part (this module acts as a gen_server for the tasks) ---
task_init([]) ->
    io:format("Task ~p: Initializing with count 0~n", [self()]),
    {ok, 0}.

task_handle_call(get_count, _From, State) ->
    io:format("Task ~p: Getting count ~p~n", [self(), State]),
    {reply, State, State}.
task_handle_call({increment, Value}, _From, State) ->
    NewState = State + Value,
    io:format("Task ~p: Incrementing by ~p to ~p~n", [self(), Value, NewState]),
    {reply, NewState, NewState}.

task_terminate(_Reason, State) ->
    io:format("Task ~p: Terminating with final state ~p~n", [self(), State]),
    ok.

% --- Entry point for runnable example ---
run() ->
    io:format("~n--- Terminating Dynamic Task Example ---~n"),
    {ok, SupPid} = dynamic_stop_example:start_link(),
    io:format("Supervisor started: ~p~n", [SupPid]),

    io:format("~nStarting Task 'temp_task':~n"),
    dynamic_stop_example:start_task(temp_task),
    timer:sleep(100),

    dynamic_stop_example:call_task(temp_task, {increment, 100}),
    Count = dynamic_stop_example:call_task(temp_task, get_count),
    io:format("Task 'temp_task' current count: ~p~n", [Count]),

    io:format("~nStopping Task 'temp_task':~n"),
    dynamic_stop_example:stop_task(temp_task),
    timer:sleep(100), % Give it a moment to terminate

    io:format("~nAttempting to call 'temp_task' after termination (will fail):~n"),
    CatchResult = try dynamic_stop_example:call_task(temp_task, get_count) of
                      Result -> Result
                  catch
                      error:Reason -> {error, Reason}
                  end,
    io:format("Call result after stop: ~p~n", [CatchResult]),

    supervisor:stop(SupPid), % Clean up the supervisor
    io:format("Supervisor stopped.~n"),
    io:format("--- Dynamic Task Stop Demo Finished ---~n"),
    ok.

Practical Use Cases

Dynamic process management is a powerful tool in Erlang. Here are some common scenarios where it shines:

  • Web Servers: Spawning a new process for each incoming client connection.
  • Connection Pools: Managing a pool of database connections, creating new ones as needed.
  • Batch Processors: Starting worker processes to handle items from a queue.
  • User Sessions: Managing individual user sessions in a multi-user application.

It allows your system to adapt to varying loads and efficiently manage transient resources.

Quick Check

You've learned about starting and stopping dynamic child processes. Let's test your understanding.

Recap: Dynamic Processes

We've explored dynamic process management, a key technique for building adaptable Erlang systems:

  • Dynamic processes are created and destroyed on demand, saving resources.
  • The simple_one_for_one strategy is typically used by supervisors managing dynamic children.
  • supervisor:start_child/2 is used to add new processes, providing a unique child specification for each.
  • supervisor:terminate_child/2 ensures graceful shutdown and removal of dynamic processes.

Mastering this allows your applications to efficiently scale and respond to changing demands.

よくある質問

「動的なプロセス管理」レッスンは無料ですか？

はい。「動的なプロセス管理」の完全なテキストはこのウェブで無料で読めます。インタラクティブに演習し（組み込みコードエディタと24時間対応のAIチューター）、Erlang OTP: Distributed & Fault-Tolerant Systems Programmingコースの残りをアンロックするには、CoddyKit PROにアップグレードしてください。 Erlang OTP: Distributed & Fault-Tolerant Systems Programmingコースには全4レッスンが含まれています。

「動的なプロセス管理」で何を学びますか？

Supervisor内で子プロセスを動的に起動・停止する方法を習得し、適応性とリソース効率に優れたシステムを実現します。 ブラウザで直接実行するハンズオンコードでErlang OTP: Distributed & Fault-Tolerant Systems Programmingを演習し、24時間対応のAIチューターがレッスンを進める中での質問に答えます。

Erlang OTP: Distributed & Fault-Tolerant Systems Programmingを始めるのに経験は必要ですか？

事前経験は必要ありません。CoddyKitのErlang OTP: Distributed & Fault-Tolerant Systems Programmingは初級者から上級者向けに構成されているため、ここから始めるか最初から始めて、自分のペースで進むことができます。 これはレッスン2/4です。

「動的なプロセス管理」レッスンにはどのくらい時間がかかりますか？

ほとんどのCoddyKitレッスンは約5～10分かかります。各レッスンはコンパクトでインタラクティブなので、着実に進歩し、ウェブとアプリ全体で正確に前回の場所から再開できます。

このErlang OTP: Distributed & Fault-Tolerant Systems Programmingレッスンでコードを書いて実行できますか？

はい。すべてのErlang OTP: Distributed & Fault-Tolerant Systems Programmingレッスンに組み込みコードエディタが含まれているため、ブラウザでリアルコードを書いて実行し、即座のAIフィードバックを取得できます。ローカル設定は不要です。

このコースのすべてのレッスン

  1. 複雑なSupervisorツリー
  2. 動的なプロセス管理
  3. 高度な再起動戦略
  4. スーパーバイザーブリッジと混在プロセス階層
← Erlang OTP: Distributed & Fault-Tolerant Systems Programmingに戻る