skymoshのスレッドAPI
shibuya.lispのLTでやったデモなどはこれくらいのAPIで十分に作れる。唯一不便なのは1スレッド1ファイルが必須になる点。
キューが無いのを不便に思うかも知れないが、I/Oに使う限りは、キューイングはOSの責任で既に行われている。mosh側で行う必要があるのは外部から来たパケットをschemeオブジェクトに変換してworkerに引き渡すことだけで、workerが仕事中につき処理できないパケットはOS側に放置しておけば良い。
ただ、通常のプログラミング習慣としては、データは可能な限り早くプロセス側に引き取るのが望ましい。そう言う意味ではキューは依然必要であるとも言える。
skymoshのスレッドAPIは一種のmultiple VM戦略であり、一切の環境を親スレッドから継承しない。一つはmoshでないVMも平行動作したいという構想のためで、skySchemeのように"コンパイルして高速に動くR6RSサブセット"と"フルR6RS"を使い分ける戦略を狙っている。skySchemeはそもそもCell B.E.のSPE向けに設計しているので、環境を共有するタイプの戦略を採ることは出来ない。
例えばskySchemeではパケットをパースしてS式に変換することに特化し、変換したS式の処理は本来のmosh VMで行うことを考える。この場合、オブジェクトはチャネルを通るタイミングで(skyScheme側からmoshのオブジェクトシステムを叩いて)変換されることになるだろう。
もう一つのmultiple VM戦略の有利な点はVM同士が疎結合になる点で、異なるノードやプロセスに分散したプログラムを直接的にサポートする手段としては望ましい。同一マシン中のプロセスで分散する意義は、ユーザ権限の適切な制限がある。スレッド間でも幾つかの制限は可能*1だが、chrootのようにプロセス単位のものしか存在しないAPIもある。
現在の実装では、親スレッドからはシンボルだけを継承する。このシンボルも選択的に提供されるのが望ましい。
現在のWin32版のMosh trunkではskymoshは幾つかの理由*2で動作しない。それ以外の環境ではそれなりに安定して動作する。
