2014年05月31日
サーバ方式ではないログの多重追記方式を考えてみる (2)
前回は LockFile の範囲が期待通りではなく、おかしい結果 (文字列がオーバーラップしていた) が得られていたが、実は、サイズ計算のミスであることがわかり、基本構造は正しかったことがわかった
前回の
の内容はそのままで、呼び出し部分でのサイズ計算を正しく実施したら、期待通り、重ならずに文字列を書き込めた
ただし、この方式は先着順ということであり、OSの制御によっては、後から書き込んだものが先に出力される可能性が残っているため、ログシステムとして考えると、ちょっと心もとない
(もちろん、後からタイムスタンプでソートすれば問題はないし、多くの場合では逆転することはなさそうだから、無視することも考えられる)
本格的に実装するなら、やはりFILOキュー方式が必要になり、そうした実装にするには、誰かがキューを制御しなくてはならない
ここでの目標は特定のサーバを設けないということなので、1つの案としては、最初に起動されたライブラリ実装が、キューを生成・管理するための仕組みを共有メモリに作成し、常に同時使用するプロセス・スレッド間で調停しながら進めるということになるのかもしれない
その雰囲気で実装できたら、ちょうど分散システムでのログ管理方式としても考えられそうだが、いかんせん、実装が Win32 に依存して (かつ、ファイルシステムAPIに依存) しているのでは、ちょっと汎用性がなさすぎだろうな
やはり、この実装が生きてくるのは、単一PC上での同一ログファイル競合くらいだという気がしてきた
前回の
void CWin32Logger::write(void* buffer, DWORD size)
の内容はそのままで、呼び出し部分でのサイズ計算を正しく実施したら、期待通り、重ならずに文字列を書き込めた
ただし、この方式は先着順ということであり、OSの制御によっては、後から書き込んだものが先に出力される可能性が残っているため、ログシステムとして考えると、ちょっと心もとない
(もちろん、後からタイムスタンプでソートすれば問題はないし、多くの場合では逆転することはなさそうだから、無視することも考えられる)
本格的に実装するなら、やはりFILOキュー方式が必要になり、そうした実装にするには、誰かがキューを制御しなくてはならない
ここでの目標は特定のサーバを設けないということなので、1つの案としては、最初に起動されたライブラリ実装が、キューを生成・管理するための仕組みを共有メモリに作成し、常に同時使用するプロセス・スレッド間で調停しながら進めるということになるのかもしれない
その雰囲気で実装できたら、ちょうど分散システムでのログ管理方式としても考えられそうだが、いかんせん、実装が Win32 に依存して (かつ、ファイルシステムAPIに依存) しているのでは、ちょっと汎用性がなさすぎだろうな
やはり、この実装が生きてくるのは、単一PC上での同一ログファイル競合くらいだという気がしてきた
【このカテゴリーの最新記事】
-
no image
-
no image
-
no image
-
no image
-
no image
この記事へのコメント
コメントを書く
この記事へのトラックバックURL
https://fanblogs.jp/tb/2463967
※ブログオーナーが承認したトラックバックのみ表示されます。
この記事へのトラックバック