課題
現在のサクラエディタのCShareDataについて考える。
問題点
- 共有メモリが固定構造体方式なので拡張性がない。
- マルチプロセスであるのに排他制御がされていない。
提案
共有メモリに格納するデータをセクションごとに分割して管理する。
配列になるデータは可変とする。
共有メモリを構築するときに合計サイズを求めて割り当て、各セクションのポインタを保持してアクセスするようにする(現在は共有メモリの先頭ポインタを超巨大構造体にキャストしたもの)。
ヘッダセクション
検索セクション
編集ウインドウセクション
タイプ別設定セクション
カラーセクション
...
キーワードセクション
...
その他セクション
セクションは入れ子になるかもしれない。
でも、そんなの関係ねー。
各セクションに対するアクセスを専用クラスを作成してカプセル化してしまう。
専用クラスはセマフォによる排他をおこなう基底クラスを継承させておき、自動的に排他してくれるというものだ。
CShareDataHeader
CShareDataFind
CShareDataWindow
CShareDataTypeSetting
CShareDataColor
..
CShareDataKeyword
...
CShareDataOther
CShareDataにアクセスするCShareDataBaseを作って基本アクセスを作成し、さらに排他制御を行うCSemaphoreクラスを継承する。
たとえばこんな感じだ。
//登録可能な検索個数
int n = lpcShareDataFind->GetMaxCount();
//排他、最近使ったリスト管理もして登録する便利メソッド
lpcShareDataFind->Add( _T("検索語") );
共有メモリが可変になるのは面倒なので、設定の変更は次回起動時でよいだろう。
int nArraySize; //現在の配列数
int nNextArraySize; //次回起動時の配列数
プログラムで参照するのはnArraySizeのほう。
設定ファイルに保存するのはnNextArraySizeのほう。
排他だけど、プロセス間で排他すればよい。
プロセス内の場合は、内部セマフォカウンタ(シングル豚でモツ)のみカウントする。
最終更新:2007年12月14日 22:03