Cygwin port status
いまのところ(r1769)上手く動いている。
gcc3 support?
#ifdef __CYGWIN__ //gcc3? #include "Gloc.h" #include "Closure.h" #include "VM-inl.h" #endif
は不要な事が分かったので、これを入れたままにするか削除するかは微妙なところ。
個人的にはgcc3のサポート*1はDROPしても良いかなという気持ち。Cygwin1.5系列は特に試していないので不明。バグレポートがあれば修正。
external functions support
今の所CygwinではFFIをサポートしていないので、外部ライブラリ(cairoとかlibusb)は全てVMFactoryにhookを設けてそこに収容している(つまりskymoshと同様の実装)。
moshの方針としては、
- 静的リンク/動的リンクを問わず、デフォルトのライブラリはport間で固定
- 固有のライブラリはFFIで提供
というもので、configureに--withとか--enableで機能を増減させることは想定されていない。
これは、
- ○ ディストリビューション間で機能が異なることが無い
- ○ インストール後からでも機能を追加/削除できる
- × 静的リンクライブラリしか提供されていない場合は、一旦別の動的リンクライブラリを経由する必要が有る
- × FFIライブラリとのやりとりはSchemeコードを介するので一定のオーバーヘッドが有る
FFIとGCの間には常に絶妙な問題がある。moshのGCは保守的GC(Boehm GC)で実装されている*2が、ポインタを受け渡す際にはやっぱり問題が起こる*3のでGC protectされたオブジェクトを割り当てる方法が必要になる。
良いパフォーマンスを実現するためには、(stdioとかで既にやっているような)一段階抽象化したコードを書く必要がある。Mosh標準機能以外にパフォーマンスsensitiveなトピックが無いのかというとそうでも無いように思う。
折衷案としては、パケットの送受信だけは特別扱いして--withとか--enableによる機能追加を許すことを考えている*4。
というのも、パケットの送受信のような各種イベントはスレッドの起床などに関わるため。つまり、多くのI/OライブラリはOS固有のI/Oシステム(fdとかファイルハンドル)と密接に関わっており、OS固有のスレッドライブラリもI/Oオブジェクトに密接に関わっている(e.g. libeventとかWaitForMultipleObject)。
configureで有効/無効がオプションとして提供されるべきなのは、
- pcap - Ethernetパケットの送受信/sniff
- libusb - USBパケットの送受信
- (OS固有の非同期I/Oルーチン)
- libeventの提供するようなネットワーク
これらが提供するルーチンをfreevarsに組み込むために、perlやRubyがやっているような２段階のビルドをmoshにも適用することになる。
moshがシェルとして利用されることを考えると、"パケット処理ができる重装備mosh"を別バイナリにしてconfigureに--enable-skymosh=usb,pcapのようなものを追加する方が望ましいかもしれない。シェルのように頻繁に起動されるプログラムでは、ライブラリの初期化に掛かる時間はおそらく無視できない時間になる。
この場合、moshがskymosh(仮)のライブラリをimportしたタイミングでskymosh(仮)を起動し、継続を作ってsky(仮)moshに渡すことになる。
他のライブラリは、大抵"適当なメモリ上のポインタを渡し、操作して返す"というスタイルで利用されることが多いため、現状のようなFFIでも特に大きな問題にはならないように思える。
