Kotani前回はovs-vswitchdのmain関数のloopの前まで見たので、今回はloopの中を見ていきます。いう変数でループを抜けるかどうか判定しています。existingの変数はunixctlでexitコマンドが送られてきたときにtrueにセットされます。あとは初期化していたいろんなものを順次走らせています。poll_block();}次のように分けて順に読んでいくつもりです。netdev_waitnetdev、bridge_*、ofproto、ofproto-dpif関係での長い処理は、それぞれ別の回で読んでいくつもりです。worker_waitこれらの関数はlib/worker.cにあります。vSwitchのRPCを別プロセスで処理する仕組み(たぶん)で、worker_run関数はRPCのreplyを処理するものです。replyのメッセージをbufferから読み出して、worker_reply構造体の中のcallback関数を実行しています。}}ちなみに、worker_request構造体とworker_reply構造体は以下の定義になっています。どちらもlib/worker.cに書かれています。loopを起こすものです。loopのところで詳しく見ていきます。signal_waitsignal_poll関数は、引数で指定したsignalを受け取っていたらtrue、そうでなければfalseを返すものです。false;}シグナルを受け取ったときはsignal_handlerが処理して、signald配列の該当するシグナルをtrueにしています。valueを決めています。loopを起こすものです。memory_waitこれらの関数は、lib/memory.cにあります。メモリの使用率を定期的に報告するものです。memory_runは報告する時間かどうかの判定、memory_should_reportは判定結果を返り値とする関数、memory_reportはunixctlを通して管理用のコマンドに使用率を送るものです。メモリ使用率のデータの収集はbridge_get_memory_usage関数内で行われています。unixctl_server_waitこれらの関数は、unixctlで管理用のプログラムからのコネクションを受け付け、コマンドを処理し、応答を返すものです。lib/unixctl.cにあります。コマンドやデータはJSONで書かれていて、データを受信したあとJSONのパース、次に登録されたコマンドの実行、そのあと実行結果を返す、という流れになっています。ここら辺は深入りしたくないので、これぐらいにしておきます。poll_blockこれらの関数はlib/poll-loop.cにあります。poll_blockは何か*_waitで指定したものが起きるかタイムタイムアウトするまでblockする関数です。descriptorのリストはwaitersというリストにあります。time_pollが実際に待っている関数です。この中ではpollが呼ばれています。fatal_signal_run();}poll_immediate_wakeはexistingがtrueのときに実行されます。poll_blockのtimeoutを0に設定していて、プログラムを終了するときにblockされることがないようにということだと思います。後回しにしている、netdev、bridge、ofproto、ofproto-dpifを順に読んでいきます。