(Shiro:2018/10/27 23:09:05 UTC) とおる。さんがlibuvとMakikiをくっつけるという面白いコードを書いている。
https://github.com/torus/gauche-violet
Makiki (https://github.com/shirok/Gauche-makiki ) には、サーバソケットで接続を待つループと、ハンドラを定義して接続があったら適切なハンドラにディスパッチする機能があるんだが、前者をlibuvに置き換えて後者だけを使っている (後者のエントリポイントはhandle-client)。ただ、今のMakikiは全て<socket>前提で書かれているのだけど、libuvを使う場合ハンドラが読み書きする直接の対象はソケットではないのでちょっと都合が悪い。なのでgauche-violetではMakikiを改造して<virtual-socket>というレイヤを導入している。
この、「直接読み書きする対象がソケットでない」というユースケースは他にもあって、rfc.httpではTLSを使う場合に<tls>をかまさないとならないのであちこちにディスパッチコードが入っている。
このへん、うまくまとめられないだろうか?
読み書きだけ考えるならポートを渡せばいいのだが、ネットワークコネクションの場合、それに加えて次の操作が必要になる。
ただ、後者については高レベルインタフェースとしては同一視してしまってもいいかもしれない(入出力両方closeされた時点でネットワーク端点を暗黙にcloseする)。
実装の方策としては、
<connection>とか。
<port>に機能を増やす
2018/10/30 10:02:39 UTC: ひとまず<connection>インタフェースを作ってみた。
https://github.com/shirok/Gauche/blob/master/lib/gauche/connection.scm
<socket>と<tls>は<connection>インタフェースを実装している。
また、外部プロセスとパイプで通信する<process-connection>も書いてみた。
すると、rfc.httpがだいぶ簡単になった。
closeとshutdownの分離
shutdownは相手との接続を終わらせること。closeはローカル側の資源の後始末。 通常の使い方ではshutdownしてからcloseする。
両者を区別する絶対的な必要性についてずっと忘れててさっき思い出したので書いておく。
接続確立後forkした場合、一方のプロセスでcloseしても別プロセスがまだ通信してる場合があるから、closeとshutdownは兼ねられない。