Google Gears: Worker Pool は 120個以上 createWorker できない

Google Gears を触っています。いくつか覚え書き。

WorkerPool class の createWorker メソッドは worker ID を戻り値に持ちます。その worker ID は“guaranteed to be unique values that are never reused within the same WorkerPool” とありますが、今の所の実装では、0 から始まる int で、119 に達すると、次に workerpool 関連のメソッドが呼ばれたらエラーを発生させ、時に無言で Firefox ごと異常終了するようです。

あと 同じく createWorker メソッドなどで、引き数の設定などが正しく行われていないと（child から parent への messaging ハンドラがないとか）、やはり無言で Firefox ごと異常終了するようです。

まぁ Beta 版ですからなんとも云えません。しかし Worker は thread というよりむしろ process と似たような振る舞い、と reference にもある以上、数に制限は必ずあるのでしょう。となると Multiton で生成、いや処理を細切りにする事自体が間違ってるのかな？UI を止めないで重たいプロセスを走らせられる、というのはスゴいけれど、僕としてはもともとそれほど重たくない処理を分散化して超高速化！見たいなのを考えていたのだけれど…

これらは全て ITP で最初にやったプロジェクトを Google Gears の上に再現してみようと思って発見しました。コードはプロジェクトが出来た時に公開したいと思います。

あと話はすこし変わるけれど、Google Gears と Adobe Air (aka Apollo) を対抗技術とするのは違うと思う。Google Gears は Safari もそのうち にもある通り Safari での動作を視野に入れている、というか開発が進んでいる。Adobe は Air の基盤技術として webkit を使っているのだから普通に考えて、Adobe Air でも Google Gears は動くようになるのではないか（いや、まぁ webkit は実際主に HTML Rendering Engine だろう、Safari の plugin 機構は webkit とは別、という突っ込みはアリだ。しかし Javascript Engine の KJS は webkit に含まれているし、もともと Google Gears だって、プラットフォーム毎に内側で使っているものは違う）。というか Adobe は動かしたいだろう。Air Beta についてきた DB は、もともと Flex で外部に頼らず DB を叩きたい、とかそういった要望に応えるもので、Google Gears の SQLite とは大分経路が違うような（このへんは追っかけてないのであやふやかも）

そうなると旗色が悪くなるのは、もともとの対抗技術である Joyent Slingshot、Microsoft Silverlight やら Sun JavaFX のような気がする。Silverlight はそりゃ Microsoft のする事だからすぐに廃れる事はないだろうけれども… JavaFX とか誰か使う奴いるのかね？Annotation の駆使とか野心的なのはわかったけど、なに Operation って？昔 同じ関数でも戻り値をもつか持たないかで呼び方が違う言語があってそれってユーザフレンドリーじゃないな、って思った事を思い出した。Slingshot はあるいは風前の灯か、MDM Zinc の二の舞か（っつぅか AIR が Zinc のパクリだが、マーケティング能力に勝る Adobe には適うはずもなく）。