Latest topics > e10sオワタ
宣伝。日経LinuxにてLinuxの基礎？を紹介する漫画「シス管系女子」を連載させていただいています。
以下の特設サイトにて、単行本まんがでわかるLinux シス管系女子の試し読みが可能！
e10sオワタ - Nov 18, 2011
- Firefoxのマルチプロセス化、当面凍結 - 直近の性能向上を優先 | エンタープライズ | マイナビニュース
- Update on Multi-process Firefox (Electrolysis) Development | Lawrence Mandel
Firefoxのプロセス分離モデルへの移行は当面行われないことになったのだそうだ。Firefox Hacks Rebootedでe10sでの開発の方法について色々書いたばかり（いや実際にその節を書いたのはずっと前なんだけど本が出たのはつい最近の事だったのですよ）なのに！
デスクトップ版Firefoxでe10sが使われないとなると、今e10sが使われてるのはFirefox Mobile（Fennec）だけということになる。そのFirefox MobileもそのうちXULを捨ててAndroidネイティブなアプリケーションとして作り直すという話もあって、そうすると本格的にe10sはオワコンっていう事になってしまう。
そうなると気になるのが、Add-on SDKだ。今のAdd-on SDKはe10sを前提に諸々のAPIが作られていたはずで、e10s前提にしないといけないからこそ、かなりめんどくさいAPIになっていたという印象がある。それが、そもそもe10sいらなくなっちゃうんだったら、後に残るのは単に使いにくいAPIだけって事になってしまう。また、仮にe10sを前提としないAPIに作り直すんだとしたら、それは「APIの互換性を保ち続ける」と言っていたAdd-on SDKの売り文句を自分で否定する事になるわけで。にっちもさっちもいかなくなって、Add-on SDKの開発をやってたチームはほんと涙目ですね。
それはそうと、中野さんはe10sには個人的に反対（マルチプロセスよりマルチスレッドだろ派）していて今回の決定は歓迎だと仰っているけれども、Geckoより上のレイヤでしか開発を行わない人間にとっては、マルチプロセスだろうがマルチスレッドだろうがあんまり変わらない（どっちにしても今より面倒になる事には変わりない）ので、「e10sオワタ！ やった！！」とか喜ぶような話でもないんですよね。
というのも、今のFirefoxではbrowser要素のdocShellからcontentDocumentとか辿っていってWebページのDOMに普通にアクセスできてっていう感じの事ができるけれども、コンテンツ領域がマルチスレッドなりマルチプロセスなりになれば、結局今のやり方は通用しなくなってしまうわけです。マルチプロセス（e10s）でもマルチスレッド（例えばWorker）でも、プロセス間・スレッド間での通信にはせいぜい文字列形式のメッセージしかやりとりしかできないので、仮にコンテンツ領域がマルチスレッド化されたとしたら、コンテンツ領域との情報のやりとりは結局やっぱりe10sのmessageManager周りのAPIと同じようなAPIにならざるを得ないのですよね。今の、WebページのDOMにChrome領域のスクリプトから触り放題な設計は、いずれにせよそのうちオワコンになっちゃうのでしょう。
オチはありません。
Rockridge氏が、あちこちに散らばってる議論を追いかけて上手い事まとめて下さっているので、追記。
e10sが本当に「とりあえず今は休止。また後で復活するかもね。」というステータスになってるんだったらいいんだけど、そうでなくて雑誌の休刊みたいに「再開させるつもりは全然ないけど一応建前上は休止ってことにしとく」という事なんであったら、Add-on SDK的にはあんまり嬉しくない事になるんじゃないかっていう心配をやっぱり僕はしてる。
e10sには「XULRunnerアプリケーションで、インラインフレーム単位で別プロセスにしてプロセス間通信できるようにする」という「Message Managerという仕組みの追加」というフェーズと、「FirefoxというXULRunnerアプリケーションをMessage Managerを使った実装に書き直す」というフェーズの2段階がある（と言える）。
このうち前者は既にできていて、後者についても、（ちょっと前までの）Firefox Mobileでは実際にこの仕組みを使うようになっていた。でもこれはFirefox Mobileがまだ生まれて間もない・機能もそんなに多くない時期だったからこそできた事で、デスクトップ版のFirefoxのようにいろんな機能が既に載ってる物では、パッチというレベルには収まらない根本的な設計変更になってしまうから、そう簡単には進められない。高速リリースサイクルでは、そんな事は無理……というわけですね。
それでFirefoxでは後者のフェーズに進まない事になったという話なんだけど、そうするとFirefox本体ではMessage Managerはどこからも使われていないデッドウェイトという事になってしまう。使われてない機能だったらメンテナンスも滞るだろうし、下手をしたらそのうち「この機能使ってないよね。削除しちゃっていいよね？」って事でさっくりソースコードから姿を消してしまう可能性だってあるだろう。SDKでe10sを使っていようがいまいがお構いなしに。
Comments/Trackbacks
TrackBack ping me at
の末尾に2020年11月30日時点の日本の首相のファミリーネーム（ローマ字で回答）を繋げて下さい。例えば「noda」なら、「2011-11-18_e10s.trackbacknoda」です。これは機械的なトラックバックスパムを防止するための措置です。
Post a comment
writeback message: Ready to post a comment.