ばぐとらぶごる

開発者もすなるぶろぐといふものを、エンバグ野郎もしてみむとてするなり。

SHIORI Callbackの現実的な実装案

SSP

id:ukiya:20070823:1187861774
より。といっても、昨日の夜に浮子屋さんに直接相談した結果がこれなのですが。

結局のところ、SHIORI Callback仕様は実際にどうやって実装すればいいのかという問題です。

現在の方法の問題

基本的に、SSTPを打ち込むしか、SHIORI/SAORIから本体をぶったたく方法はないわけで…

Socket SSTP
  • ガジェットに毛が生えたようなアプリがListenしてるのはよく考えたらあまりよろしくないかも
  • 本体機能を叩くためだけにネットワークプログラミングもどきを強いられるのはよろしくない
Direct SSTP
  • ウインドウを最低2枚1組用意しなければならない。本体側はふつうにできるがSHIORI/SAORIがやろうとすると自前でメッセージキューをまわすスレッドを立ち上げてとかものすごく面倒。
  • だいたい、Windows依存すぎ。

新しい方法の案

1.関数ポインタを渡してそれを呼ばせる
  • 利点
    • とにかくやたらと低コスト。
    • その気になればOSを問わず使える技法。
  • 欠点
    • なんだかすごくキチャナイ気がする。
    • 32bit/64bitの橋渡しをどうするか、あるいはマネージ環境から使うにはどうするか。今時考えるべき仕様ではない。
2.パイプ
  • 利点
    • とりあえず、まともなOSには実装されている。
    • 名前なしパイプでも、SHIORIにハンドルを直接渡せばいけるのでWin9x/NT4系を切らなくていい（いいかげん切ってもいいんだろうけど）
  • 欠点
    • 所詮「パイプ」なので、ある一定のバッファサイズを使い切るとヘタこいたらデッドロック直行。
    • 当然、Queuingもされない。
3.メールスロット
  • 利点
    • 勝手にQueuingの面倒まで見てくれるので楽。
    • 「名前」がつけられるのでSHIORI以外の外部から叩くI/Fにも使えないこともない
  • 欠点
    • ひどいWindows固有仕様orz（似たような仕組みはあるらしいが…SysV IPC Queue / POSIX Queue）
    • それ、しなちくのSIPC.Mと何が違うの？
4.ファイルなしFMOとMutex/Semaphoreの組み合わせ
  • 要するに手動パイプなのでボツ。
5.DDE
  • 要するに難解なDirect SSTP(WM_COPYDATA)なのでボツ。

総合すると、やっぱりメールスロットに落ち着くんでしょうね。かつてSIPCの時も最初はパイプで実装してみてひどい目に遭ったのでメールスロットに落ち着いたという過去がありますし。