17.1.1. init¶

最初の1つは init/1 関数です。これはサーバの状態を初期化して、サーバが依存する1度きりのタスクをすべて行うという点で、 my_server で使ったものと似ています。 この関数は {ok, State}, {ok, State, TimeOut, {ok, State, hibernate, {stop, Reason} あるいは ignore です。

通常の {ok, State} の返り値は State がそれ以降維持される状態としてプロセスのメインループに直接渡されることを過去に言っているので、特に説明の必要はありません。 TimeOut 変数はサーバがメッセージを受け取るのに締め切りが欲しい時にタプルに追加して下さい。 もし締め切りまでにメッセージが1つもこなかったら、特別なメッセージ (timeout というアトム)がサーバに送られます。これは handle_info/2 に処理されるべきです。（後述します）

一方で、返信を受け取るまでに長い時間を確保したくて、メモリが心配なときは、タプルに hibernate というアトムを追加できます。 ハイバネーションは基本的に、処理能力を犠牲にして、メッセージを受け取るまでプロセスの状態のサイズを減らします。 もしハイバネーションを使うことに懐疑的であれば、使う必要はないでしょう。

{stop, Reason} は初期化の途中でおかしなことが起きた時に返されるべきです。

17.1.2. handle_call¶

関数 handle_call/3 は同期メッセージと連携するときに使われます。(同期メッセージの送り方についてはすぐに触れます) この関数は Request, From, State の3つの引数を取ります。 my_server で実装した handle_call/3 ととても良く似ていますね。 最も大きな違いはメッセージの返し方です。 私たちが行った独自のサーバ抽象化では、プロセスにメッセージを返すために my_server:reply/2 を使う必要がありました。 gen_server では、8つの戻り値があり、それらはタプル形式です。

戻り値がたくさんあるので、一覧で並べてみました:

{reply,Reply,NewState}
{reply,Reply,NewState,Timeout}
{reply,Reply,NewState,hibernate}
{noreply,NewState}
{noreply,NewState,Timeout}
{noreply,NewState,hibernate}
{stop,Reason,Reply,NewState}
{stop,Reason,NewState}

すべてにおいて、 Timeout と hibernate は init/1 に対して行なっていたのと同様です。 Reply に何が入っていようと、それがと最初にサーバを呼び出したところに送り戻されます。 noreply に3つのオプションがあることに注意して下さい。 noreply を使うと、サーバの全体的な部分は自分自身に送る返信に関する処理をしている、と想定するでしょう。 この処理は、 my_server:reply/2 で使われたのと同様に gen_server:reply/2 で行うことができます。

たいていの場合は、タプルを返すだけで良いでしょう。 さらに、 noreply を使う正当な理由が理由がいくつかあります。 たとえばあなたに返信を送る他のプロセスが欲しい時はいつでも、あるいは確認応答(‘メッセージ受け取ったよ!’)を送りたいけれど、まだ(今回は返信しない)プロセスが続くとき、などです。 もしここに挙げたのような事をしたいのであれば、絶対に gen_server:reply/2 を使う必要があると言えましょう。なぜなら、そうしなければ呼び出しがタイムアウトして、クラッシュの原因となってしまうからです。

17.1.3. handle_cast¶

handle_cast/2 のコールバックは my_server で実装したものととても似た動作をします。 Massage と State を引数に取り、非同期呼び出しを処理します。 そのコールバックではやりたいことは、 handle_call/3 で出来たこととほぼ同様になんでもできます。 一方で、戻り値は reply がないタプルだけが有効な値となります:

{noreply,NewState}
{noreply,NewState,Timeout}
{noreply,NewState,hibernate}
{stop,Reason,NewState}

17.1.4. handle_info¶

私達のインターフェースに合わないメッセージは上手く扱えないことに関して私が言ったことは覚えていますよね。 そこで handle_info/2 の登場です。 handle_cast/2 にとてもよく似ていて、事実同じタプルを返します。 違いは、コールバックが、 ! 演算子で直接送られてきたメッセージや、 init/1 の timeout のような特別なメッセージ、モニターの通知や 'EXIT' シグナルのためだけに存在する、ということです。

17.1.5. terminate¶

コールバック関数 terminate/2 は3つの handle_xxx 関数が {stop, Reason, NewState} または {stop, Reason, Reply, NewState} という形式のタプルを返した時にいつでも呼ばれます。 この関数は、 Reason と State という引数を2つとり、これらの引数は stop のタプルにあるものの値と同じものとなります。

また terminate/2 は、その親(自身を生成したプロセス)が死んだ時、かつ gen_server が終了を捕捉していた場合にも呼ばれます。

この関数は init/1 とは正反対であり、 terminate/2 の結果もまた init/1 で行われたことの正反対となります。 この関数はいわばあなたのサーバの守衛であり、全員が出ていったかを確認した後にドアをロックする役割を果たしている関数なのです。 もちろん、この関数はVM自身にサポートされているものであり、VMはあなたの代わりにすべてのETSテーブルを削除したり、すべてのポートを閉じたりしてくれています。 この関数が呼び出された後にコードは処理を停止してしまうので、この関数の戻り値が重要なのではないということに注意してください。

17.1.6. code_change¶

関数 code_change/3 はコードをアップグレードするためにあります。 この関数は code_change(PreviousVersion, State, Extra). のような形で呼び出します。 ここで、 PreviousVersion という引数は、アップグレードする場合は自身のバージョン項(バージョン項について忘れてしまった人は モジュールとは何か を読んでください)を指定し、ダウングレード(古いコードを再読み込みするだけ)の場合は {down, Version} を指定します。 State 変数は、現在のすべてのサーバの状態を保持していて、変換して使えるようになっています。

orddictを使ってすべてのデータを保存していた時のことを想像してみてください。時が経ち、orddictでは処理が遅すぎるようになってしまったので、通常のdictに変更することにしました。 次の関数呼び出しの時にプロセスがクラッシュするのを避けるために、あるデータ構造から別のデータ構造への変換はそこで、安全に、行うことができます。 新しい状態を {ok, NewState} として返すだけで良いのです。

Extra 変数はいまは木にする必要の無いものです。 この変数はもっと大きなOTPデプロイに使われるもので、その場合はVM上のリリース全体をアップグレードする特別なツールも存在しています。 まだ、それについて触れるのは早いので、ここでは触れません。

これで定義されたコールバックをすべてを見ることが出来ました。 もしちょっとわからなくなってしまったとしても心配しないでください。OTPフレームワークは循環的に定義されているところがあって、フレームワークのAという部分を理解するためにはBという部分を理解する必要がありのに、Bを理解するにはAを参照する必要があったりします。 こうした混乱を上手く乗り越える最善の方法は、実際に gen_server を実装してみることです。