preforkサーバーの挙動について（forkの挙動、オープンファイル記述の共有の謎）

Question

背景

プロセスについて説明されているサイト（preforkサーバーを作ってみよう）を読んでいました。

その中でpreforkサーバが触れられており、以下のコードが示されていました。

# -*- coding: utf-8 -*-
require "socket"

number_of_workers = 3
listening_socket = TCPServer.open(12345)

number_of_workers.times do
  pid = fork

  if pid
    # 親`プロセス`は次々に fork で子`プロセス`を作る
    next
  else
    # 子`プロセス`

    # クライアント受け入れ無限地獄
    loop do
      puts "`accept`ing..."
      # 子`プロセス`は全部ここでブロックする。
      socket = listening_socket.`accept`
      puts "`accept`ed a client!"

      # クライアントの入力受け取り無限地獄
      loop do
        line = socket.gets
        line.gsub!(/[\r\n]/,"")

        if line == "exit"
          socket.close
          puts "closed a connection!"
          break
        end

        puts line
      end
    end
  end
end

# 子`プロセス`は無限ループしてるからここには届かない
# 親`プロセス`では子`プロセス`の終了を待ち続ける
Process.waitall

このサーバーは以下の流れで動いているかと思います。

流れ

1. リスニングソケットを作られる
2. forkして子プロセスを三つつくる
3. ３つ全ての子プロセスのリスニングソケットがaccept（接続待ち状態）に以降する
4. 子プロセス達はリスニングソケットのオープンファイル記述が共有されている事から、外部Aから接続が来た場合、3つのうち1つのプロセスだけ接続される

(一番処理が先に進んだどれかのリスニングソケットに接続されると、オープンファイル記述に外部Aと接続してるよ！と書かれるから、その他の子プロセスのリスニングソケットは「なんだもう外部Aとは接続されてるのか」となり、特段なにもしない)
5. 外部Bから接続された時は、余っている子プロセスのリスニングソケットが対応して同じような事をする

これを読んでいて疑問がいくつかわきました。

疑問

その１

流れ3にて一番処理が速かったプロセスのリスニングソケットがaccept（接続待ち状態）に以降した時に、オープンファイル記述には「今俺accept（接続待ち状態）しているよ！」という旨の文言が書かれてしまい、他のプロセス達はaccept（接続待ち状態）していないにも関わらず自分の事をaccept（接続待ち状態）していると勘違いしないのか？
（accept（接続待ち状態）処理をしようとすると既にaccept（接続待ち状態）していますエラーが出たりしないのか？）

その２

最初に外部Aと接続した子プロセスのリスニングソケットは、接続済みソケットを生成したあと再び待ち状態になるかと思うけど、この子プロセスのリスニングソケットが再び接続を受け取ってしまう事はないのか？

もしリスニングソケットが一度接続済みソケットを生成したら休止状態に入るとするならば、ファイルオープン記述を共有している他の子プロセスのリスニングソケットもみんな休止状態に入ってしまい結局一つしか接続できない事になってしまう為、rubyのソケットも一般的なTCPソケットのaccept挙動と同じく、接続済みソケットを生成したあと再びaccept（接続町状態）になると考えています。

所感

オープンファイル記述で共有される内容がよくわからない・・・

Answer 1

疑問がわくのは恐らく、OSのカーネル(Linuxカーネル)側の処理を失念されている為かな、と思いました。

---

疑問その1について

他のプロセス達はaccept（接続待ち状態）していないにも関わらず自分の事をaccept（接続待ち状態）していると勘違いしないのか？

勘違いしません。勘違いする余地が無いようカーネルが管理し、処理を割り振りしています。

（accept（接続待ち状態）処理をしようとすると既にaccept（接続待ち状態）していますエラーが出たりしないのか？

エラーにはなりません。これもエラーにならないよう、カーネルが管理、処理の割り振りをしています。forkで起動した子プロセス同士で同時にacceptを実行しても問題ありません。更に言えば、同一プロセス内で複数のスレッドを起動し、それぞれでacceptを実行しても問題なく動作します。
(Linux ubuntu1604-x64 カーネルバージョン4.15.x 上で、Rubyスクリプトではなく、C言語ベースでfork, pthreadを利用して確認しました)

親プロセスでlisten後にforkされた子プロセス群は、acceptを実行するときにそれぞれがacceptの処理を"自分で"行っているように見えるかもしれません。しかし実態はacceptと言うシステムコールを呼び出した時点で処理がカーネルに委ねられ、プロセスが停まります。（その為、クライアント側から接続するまでは処理がブロックしているように見えます）その後の処理はカーネルが引き継ぎます。

acceptシステムコールは言うなれば「接続を受け付けてください。それまで私は寝ますので、接続されたら起こしてください」とカーネルに依頼するシステムコールです。別の子プロセスが既に接続待ちしていても、接続時に割り振りが変わるだけです。

カーネルのプロセス管理機構は親プロセスと親プロセスからforkした子プロセスの関係を把握していますから、TCPクライアントから接続があると、acceptを実行したそれぞれの子プロセスの内、適切なものを選んでその子プロセスのacceptから返り、その子プロセスのみが実行を再開するようにします。他の子プロセスはカーネルにより停止させられたままです。他の子プロセスが他のクライアントからの送受信を行っている場合でも、矛盾がないようにカーネルが管理しているので、疑問のような問題は起きません。

---

疑問その２について

この子プロセスのリスニングソケットが再び接続を受け取ってしまう事はないのか？

無いです。疑問その1への回答と同様、そうならないようカーネルが処理しています。疑問を更に生じさせている原因のひとつは、forkシステムコールで生成された子プロセスでは、親プロセスのforkを実行した時点のプロセスメモリの内容やカーネルリソースの一部がコピーされ、分岐して起動されることにあるかもしれません。forkはUNIXの初期からあるシステムコールですが、不思議に思えるかもしれない挙動で、カーネルも矛盾がないように管理して動作させています。

オープンファイル記述で共有される内容がよくわからない・・・

「オープンファイル記述」と言う単語自体はLinuxのmanページですとopenシステムコールの説明に出てきますね。今回はソケットの話ですが。

linux man(2) - open

open() を呼び出すと、「オープンファイル記述」 (open file description) が作成される。ファイル記述とは、システム全体のオープン中のファイルのテーブルのエントリーである。 このオープンファイル記述は、ファイルオフセットとファイル状態フラグ (下記参照) が保持する。 ファイルディスクリプターはオープンファイルっ記述への参照である。

「オープンファイル記述」 の内容の詳細はLinuxのカーネルの中身を探ってみないと分かりませんが、親プロセスが作成した「オープンファイル記述」の原本データを、カーネルはforkシステムコールの実行時にコピーや参照用のインデックスを作成して、プロセス内や子プロセスを含む外部プロセスとの関係で矛盾が無いよう、管理しているわけです。

Comments

[domidomi]

詳細なご回答大変感謝します。
私は「オープンファイル記述」の事を現在プロセスがどんな状態にあるのか記述されているメタデータだと勘違いしていたようです。

確認なのですが、
今回の場合、リスニングソケット（ソケットはファイルであると認識しています）の状態（接続積みであるとか未接続であるとか）はオープンファイル記述に記載されているものではなく、カーネルがその状態を理解しているもので有る為、オープンファイル記述が共有されていても特段問題なく複数TCPクライアントの接続を受け付ける事が出来るという認識であっていますでしょうか？

[dodox86]

メタデータと読んで良いかどうか判断つきかねますが、「オープンファイル記述」と称することの出来るデータは存在するはずです。それはあくまでプロセスと結びついて現在オープンしているファイルを間接的に指し示すものであるはずで、その範囲では、ご認識の通りだと思います。

リスニングソケット含めソケット＝ファイル、と言うのは上位のプロセスから見てあるところまでは合っているのですが、末端ではそのソケットはTCP/IPスタックやデバイスドライバーが関係していて、低レベルでのデータ構造では違っています。「ファイル」として扱えるよう、デバイスドライバーと連携し、調停して、さも「ファイル」として扱えるように振舞っています。反対に、「ファイル」としてみた場合にはソケットとしては限界もあって、ソケットの作成はopenではなくsocketですし、接続が確立したソケットのファイルディスクリプターに対して読み書きはread/writeも使えますが、ソケットとして使う場合には機能が足りない場合もあり、そんな場合はソケット用の読み書きシステムコールであるrecv/send、その他様々なフラグやオプションを使う必要があります。「ファイル」として扱える部分では「オープンファイル記述」を用いて読み書きはじめ共有や排他、他プロセスとの矛盾なきアクセスの機能をカーネルは提供している、と言うことになります。

> カーネルがその状態を理解しているもので有る為、オープンファイル記述が共有されていても特段問題なく複数TCPクライアントの接続を受け付ける事が出来るという認識であっていますでしょうか？

はい。実際にどこまで共有しているかそれともコピーなのかまでは私自身は分かりませんが、確かに言えることとしては、ファイルディスクリプターと「オープンファイル記述」の内容と管理に責任を持つのはシステムコールを呼び出した後のカーネルなので、任せて問題なく動作します。（と、言いますかUNIX系OSはもともとマルチプロセス、マルチタスクのOSとしてそのように発展してきた）

[dodox86]

しかしながらそもそも、「どうしてこれでちゃんと動作するのか？」と言うご質問に対して「ちゃんと動くよう、OSがそう造られているから。」と言う、何かごまかしたような回答だったとは私自身も自覚しているので、長い説明の割りにはいまいちかな、思っていました。だまされたような気になったとしたらすみません。