CProcessFactoryを廃止してサクラエディタをシンプルにする

[berryzplus]

概要

サクラエディタのプロセス起動の肝であるCProcessFactoryを廃止できないか検討します。

経緯

CProcessFactoryというクラスがあります。

sakura.exeの起動直後にコマンドラインパラメータを解析し、
妥当な「プロセスクラス」のインスタンスを生成して
起動したプロセスクラスの動作要件を整える役割のクラスです。

現在のサクラエディタは、CProcessFactoryが生成する
コントロールプロセス（＝共有メモリを確保するプロセス）と
エディタプロセス（＝一般の人が「サクラエディタ」と認識するウインドウを表示するプロセス）とを
協調させながら動作する「システム」になっています。

テキストエディタを動作させるのに「システム」が必要かというと、必要でないのは明らかだと思います。

サクラエディタがこのような「システム」を必要としている理由は、
sakura.iniから読み込んだデータを仮想メモリ空間にマッピングしてプロセス間で共有させる仕組みを採っているからです。

単純に「廃止」だけを考えてしまうと、今までできていたことの一部ができなくなってしまいます。

代替方式を探して導入し、共有メモリの機構を新方式に置き換えます。
代替方式があれば「コントロールプロセス」を廃止できるようになるので、そのためのCProcessFactoryも役目を終える感じになります。

ちょっと道のりが長そうなので、まずはやりたいことだけを書いてみました。

今後は共有メモリ（＝DLLSHAREDATA）を廃止する方向で動こうと考えていますが、廃止できない理由とかあったら教えてください。

[kengoide]

今の各プロセスがUIを持って、共有メモリを誰でも書き換えられる構造だと、確かにコントロールプロセスの存在意義がなんだかあやふやな気がしていました。

個人的には冒険的な考えもありまして、コントロールプロセスがすべてのウィンドウを保有して、エディタプロセスはドキュメントの管理に特化する、初期の Google Chrome のような設計も考えられるのではないかなと。

タブバーの挙動が怪しい問題の根本的な解決策になりますが、実装がそこそこ大変、リリースできる品質にするのは死ぬほど大変という欠点があります…。

[berryzplus]

今の各プロセスがUIを持って、共有メモリを誰でも書き換えられる構造だと、確かにコントロールプロセスの存在意義がなんだかあやふやな気がしていました。

段階的な改善案の1つとして、GetDllShareData() の戻り値をconstに変更してみようかと考えたことがあります。

sakura/sakura_core/env/DLLSHAREDATA.h

Lines 36 to 43 in 503d619

	//DLLSHAREDATAへの簡易アクセサ
	inline DLLSHAREDATA& GetDllShareData()
	{
	extern DLLSHAREDATA* g_theDLLSHAREDATA;
	assert(g_theDLLSHAREDATA);
	return *g_theDLLSHAREDATA;
	}

現状の構造の「何がマズいか？」を突き詰めると、この関数が書き込み可能な共有メモリを返してしまうことが起点のような気がするからです。

エディタプロセスを起動するためには、コントロールプロセスが必要。
　👇なぜコントロールプロセスが必要？
コード全体がコントロールプロセスが初期化するグローバル変数に依存しているから。
　👇なぜグローバル変数に依存？
システム全体で同期したいデータをプロセス間共有メモリに入れる構成をとっているから。

グローバル変数使っちゃダメなの？
・・・そんなことはないと思います。
プログラム全体で共有したいデータを参照するための手法としては有用だと思います。
プログラム全体で共有したいデータを更新するときどうするかを考えないといけないので、可能であれば使わないほうがよいと思ています。サクラエディタには共有データを更新するときにデータをロックするための仕組みがありますが、適用範囲は部分的でほとんど機能していません。つまり「共有データを更新するときどうするか？」を十分に考えていない状態で動いています。

GetDllShareData() の戻り値をconstに変更すると、
共有メモリに書き込みアクセスする意図のコードがコンパイルエラーになります。
（書き込み意図はないけど変数宣言にconst付け忘れたコードも巻き込まれてエラーになりますが・・・）

修正範囲が広すぎて、いままでPR出したことはないですけど、
そういうアプローチもあるんじゃないかな？とぼく個人は思っています。

タブバーの挙動が怪しい問題の根本的な解決策になりますが、実装がそこそこ大変、リリースできる品質にするのは死ぬほど大変という欠点があります…。

この問題は、タブグループに属するウインドウの管理をエディタプロセスが行っていることが原因と思っています。

• 開いているウインドウの一覧はコントロールプロセスが管理している。
• ウインドウ制御はエディタプロセス側で行っている。
• ウインドウ制御の「ぬし」を決めるロジックがある。
• ウインドウ制御が実行されると、コントロールプロセスが持っている「開いているウインドウの一覧」が更新される。
• ウインドウ制御の進行中であっても、ユーザーはウインドウを閉じたり開いたりを実行できる。
• ウインドウ制御が必要なとき、コントロールプロセスから「開いているウインドウの一覧」を取得する構成になっている。

ウインドウ管理をコントロールプロセスに一元化することで解決しそうな問題だと思っていますが、これについてPRを作成したことはなかったと思います。エアロスナップの対応を検討したときに気付いてはいましたが・・・。