週刊mosh - 実行権限の管理 / 疑似FFI

0.2.7に向け細かい改善モード のはずなんだけど色々とまだ手を入れています。今週末をメドにRCフェーズを始める予定。

修正されたIssue

意外と見落しがち。。今回Readerのバグがそれなりに直ったので、一旦R6RS test suite側へのフィードバックを検討したほうが良いのかも。

これもReaderの問題。

前回( http://d.hatena.ne.jp/mjt/20110110/p2 )の話題。

これもReader。

これも前回の問題。

報告/reopenされたIssue

これは現在作業中。互換性に関する懸念はだいたい払拭されたので、同梱のBoehmGCとの選択制にする予定。
同時にBoehmGC 7.2alpha5へのアップデートも計画中。Win32/64でParallel markに対応したのと、Linux MIPS、Andoroid対応のため。
Win64でのParallel markingは手元のベンチマーク(コンパイラ)で20%程度の性能向上(4 cores)とかなり良い感じ。

R6RSはこれといってdisplayのセマンティクスに関しては既定していないけど、特に等価にしない理由は無いような気もする。考え中。
もちろん、R6RSポータブルなプログラムを書くならput-charを使うのが望ましい。(例えば、ターミナルを保護するためにprintableでない文字をエスケープするという実装は考えられる。)

ライブラリの追加

facebookを制御するためのライブラリが追加されています。その名も(facebook)。
しかし、そろそろnaming conventionを考えないと、ライブラリルートにファイルが増え過ぎるような。。

  • bytevector-pointerとpointer-copy!

bytevectorをpointerオブジェクトとして参照するbytevector-pointerとmemcpyをpointerに対して行えるpointer-copy!を追加しました。
従来、moshFFIでは”ライブラリがバッファを返してくる"タイプのAPIを使うことができなかったので、少くとも一旦コピーで実装できるように。。これらの手続きはnmoshでSQLiteを使う場合専用なので今のところpsyntax-moshには提供されていません。

実行権限の管理

moshFFIが実行可能領域を書き込み可能にするので、SELinuxに引っ掛る問題。ただ、これはKnown Issueになる可能性が濃厚。(libffiがやっているように、W^Xを満たすようにちゃんと制御する必要がある。)
ただ、現状のExecutableMemoryクラスはデザインが不味くて、意図しない場所をexecutableにする可能性が有る。本来、executableかどうかの設定はページ単位でしか行えないので、通常のheapから確保したメモリを実行可能としてマークするのではなく、実行可能メモリ自体を独自のアロケータで管理するのが望ましい。
たとえばlibffiはdlmallocを使っている。

ExecutablePageクラスを準備して、アロケーションや書き込みはScheme側で済ませる実装が好ましいように思える。

ライブラリスタブの生成と疑似FFI

ライブラリスタブの生成を実装した。

Library.scmという名前でエクスポートするC関数のデータを書いておくと、自動的にそれに対応したライブラリを(gen-git-build.shの中で)生成します。
ついでに"疑似FFI"の仕組みを追加。疑似FFIは、moshの実行バイナリ中の関数ポインタをFFIのインターフェース経由で呼び出すもの。
普通にFFIで呼び出せば良いじゃないかという話も有るけれど、疑似FFIのメリットは"アプリケーションに静的リンクしたライブラリもFFI同様に扱えること"。具体的には、SQLiteを静的リンクしたWin32向けmoshが必要になったので実装した。
これらのまわりくどい仕組みを準備する最大の動機は、"システムネイティブのオブジェクト機構に対応するため"。システムネイティブのオブジェクト機構としては:

  • WindowsならCOM(Component Object Model)。COMは.netに移行しつつあるが、それなりにちゃんとしたbridgeが有るので、まずはCOMに対応することが必要。もちろん、.netの言語はCOMにネイティブな言語として機能する。
  • Linux/BSDはGObject(-introspection)。すでにR6RS実装は存在するが、LGPLv3なので自前のものを実装予定。( http://live.gnome.org/sbank )。GObjectにネイティブな言語としてはValaが有名。ValaはC言語にトランスレートされて動作する。
  • MacOS XObjective-C(Cocoa)。CocoaはBridge SupportとしてインターフェースがXMLで公開されている( http://bridgesupport.macosforge.org/ )。Objective-Cにネイティブな言語はもちろんObjective-C。。今のところRubyCocoa等と同じアプローチを取ろうとしている。

これらを一度やれば、いわゆる"ネイティブなGUIアプリ"を書くための素地ができる。
COMとGObjectはネイティブのタイプライブラリ(API仕様を記述したバイナリ)とそれをアクセスするためのAPIが別に存在するので、どちらを使って実装するかが絶妙に難しいところ。。