C++, boost::thread : スレッドの生成と実行
C/C++でスレッドを扱う場合は、プラットフォームによって使用するライブラリが違います。 Windows なら Windows API の thread で、 UNIX や Linux 系ならば pthread ライブラリ等を使用します。プラットフォーム依存するコードは可搬性に難があり、解決策の1つとしてプリコンパイルで依存部分をプラットフォームに合わせたライブラリを選択してコンパイルする方法があります。 boost ライブラリの boost::thread は、上のような処理をラップして共通のインターフェイスとして実装されています。 boost/thread.hppの一部 #if defined(BOOST_THREAD_PLATFORM_WIN32) #include <boost/thread/win32/thread.hpp> #elif defined(BOOST_THREAD_
Python: 辞書の初期化・出力・代入
ソースコード #!/usr/bin/python # coding: UTF-8 # 辞書とは: リストに似たデータ型で、要素(値)を指定するのに数値以外のデータ型(key)を使用することが出来る。 # key(キー)とそれに対応するvalue(値)のペアが「辞書の一要素」となる。ハッシュみたい # 辞書の初期化 dic1 = { 1:'robot', 'two':'AI' , 3:['Maya', 'Shade']} dic2 = { (1, 3):'tuple' } dicE = {} # 空の状態で初期化 # ↑書式 {key1:VALUE, key2:VALUE, ...} keyの重複はNG, valueはOK # keyとvalueはコロン「:」で繋ぐ # 辞書中のkeyの型は混在してもOK # keyになれる型はimmutableな整数、文字列、タプルなど # valueの型
java.io.StreamCorruptedExceptionが発生した原因とその解決策の一例
以前というかこの頃Javaで簡単な分散処理サーバ・クライアントシステムのモデルを実装中にこのjava.io.StreamCorruptedExceptionという例外が発生。 StreamCorruptedExceptionの発生原因 結論から言えば、恐らく実行中のスレッドの数がマシンスペックに対して多すぎたのではないかと推定（推定どまり）。 サーバが複数のクライアントを受け付けるので、クライアントのソケット接続（accept時）毎にスレッドを生成する方法を採った。この時はブロッキング型のモデル（この頃ノンブロッキング型は知らなかった）。 例外の発生状況はサーバプログラムをテスト動作時、絶えず約1000クライアントからのリクエストを受け付け、かつレスポンス等を行った場合。なお送受信データはシリアライズされたオブジェクトで、サイズは平均5KB。その時テストマシンで走らせたスレッド数が約500
シェルスクリプトでプロセスを監視し自動実行＆自動kill
追記：プロセスの監視＆自動復旧(簡易版) 今ある検索エンジンのデバッグを行っていますが、事情により短期間ですがクローズドな環境で運用されることになりました。構成は大きく分けてエンジンモジュールサーバ、クエリーモジュールサーバの二つのサーバからなっています。 デバッグはまだ途中なので、運用中にクエリーサーバorエンジンサーバのどちらか、もしくは両方が落ちる可能性もあります。落ちた場合は、手動で起動しなおすことになっていますが、せっかくなので自動化しよう。と、考えました。最初はcronデーモンを用いようと思いましたが、プロセスの監視(dead or alive)の仕方が分からず(調べきれず)、シェルスクリプトを用いることにしました(とは言うもののシェルスクリプトを使うのも初めてでした)。 クエリーサーバ&エンジンサーバのプロセスを一定の間隔で監視し、一方が何らかの原因で落ちた際は、再び二つのプ
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
