diaryこの広告は、90日以上更新していないブログに表示しています。2015-01-03Rack、WSGIサーバのThread処理の実装について(1)はじめに本記事では、あえてRack,WSGIサーバと言っているが、いわゆるWEBアプリケーションサーバ以外のサーバソフトウェアの実装でも共通の話題である「クライアントからの接続ー通信処理」の実装方式として、NativeThreadのパターンとGreenThreadのパターンの2つの違いを自分用に2回にわたってメモ事前知識ソケットプログラミング等で、チャットプログラム等を作ったりしたことがある人は、ご存知かもしれないが。サーバの通信処理がどのようなフローで行われるかを少しここでおさらいする。サーバソケット(通信要求を受け付けるためのソケット)を作成するサーバソケットを指定のIP(通常、0.0.0.0でどのIFのIPでも受けれるようにする)、指定のportで通信要求を待つクライアントからの通信要求をacceptするクライアントと通信路が確立される見て分かると思うが、1プロセス1スレッドでサーバを実装してしまうと、同時に1つのクライアントしかさばけないため、3と4の間で各クライアントごとにスレッド、プロセスを生成して4以降のクライアントごとの処理はスレッドやプロセスに任せるのが一般的である。0:00.00なんで最初から、ネイティブスレッドが1つ作られているんだ?と思ったけど、後述するnetstatの結果より、ipv4,v6で1つずつ接続待ちのスレッドを作っていると思われるcurlでwebappにアクセスしてみる。0:00.03Threadが2個増えた!1つが先ほどのcurlからのリクエストを担当し、もう1つは次のクライアントのためにあらかじめスレッドを作成しているものだと思われる。curlのリクエストが終了したら、1つ減った。う〜ん、もしかしたら、1つ多いスレッドは次のクライアントのためのものではないかもしれない。1の4種類のネイティブスレッドでWEBrickは実現しているようです。クライアントの処理がNativeThreadだと何がいいのかNativeThreadのスケジューリングは、OSのプロセススケージューラによってスケジューリングされるため各スレッドは、コアの分だけ同時に動くことができる。端的に言うと各ThreadがOSに認識される。そのため、先ほどのsampleプログラムであるTestAppのcallメソッドの中に、sleep(1000)などのブロック関数があっても別のクライアントに影響を与えないのだ。題材である、WEBアプリだとあまりないシチュエーションかもしれないが、各スレッドが独立して動くのでスレッド同士影響を与えないよう、スレッドセーフであることをきちんと確認する必要がある。読者になる検索リンクヘルプはてなブログお知らせ最新記事OpenStackで使用されているプラグイン機構Stevedoreの使い方pythonパッケージからdebファイルを作成するIronicをDevstackでサク?っと試してみたRack、WSGIサーバのThread処理の実装について(1)Backlogってなんぞや月別アーカイブはてなブログをはじめよう!ukinauさんは、はてなブログを使っています。ブログを報告するスターをつけました引用をストックしましたストック一覧を見る閉じる引用するにはまずログインしてくださいログイン閉じる引用をストックできませんでした。再度お試しください閉じる限定公開記事のため引用できません。