libtrusterd.md

boot_from_file_path_cgi

mrbAddCgiCallBack

cgi_proc

ホスト側の関数を実行させ、結果を 文字列で受け取り、mrubyの文字列に変換して返す

idea

コールバック内でCGIやサーブレット的なことさせて戻ってくる

• 文字列を返す関数を登録できるようにする　<- 一番単純

• 疑似的なreqやresをもつapiの提供　形式だけなら容易だが、実装できんのか？

char *procwebrequest(char *req)
int procwebrequest(char *req, char *res)

課題

• メモリリーク

• 原理的にかなり厳しいのかも

• リーク上等、多重化して、定期的に殺す！発想の転換！

• リクエストオブジェクトのシリアライズ

• pp 使ってもCオブジェクトはうまい事、展開してくれなかった。

  • Requestヘッダーのハッシュを返すようにTrusterd本体にプルリク

通知機能

127.0.0.1:8080等のURLをアナウンスする

trusterd.conf.rb編集機能

• webベース？
• Atom.io？

動的にmrbgemsを組み込みなおす

自分自身を作り直す

機械学習によるホスト言語とのAPI自動最適化

pythonは機械学習盛んだから、trusterdのuriマッピング時のパラメータの配置問題とか（そんな問題があるのかもよく分らないけど）

作業メモ

trusterdのプロセス制御

mrb_http2_server_run

setsockopt(fd, SOL_SOCKET, SO_REUSEPORT, (char *)&on, sizeof(on));

config->worker

trusterd.conf.rbの自動リロードの実装

kqueueのまとめ

inotifyはいい感じでディレクトリを指定すると更新イベント時にファイル名の通知されるっぽい。 しかもmruby-inotifyがある！

しかし、kqueueはできない模様。

ファイルが存在していると可能性が高い場合、ファイルとディレクトリを監視 ファイルのが削除されたら、ディレクトリのみの監視

やればやるほど、定期的にlsでもして差分があれば、リロードで良い気がするのは気のせいだろうか。

mruby-kqueue、ブロックを理解するとmruby-inotifyベースで出来そうだけど、 まずはCベースで機能としてlibtrusterdに実装することを優先して進める予定。

mruby-inotify使ってみる

Done

共有ライブラリのシンボル一覧表示機能

/ldd

課題

コールバックで文字列を返すと、メモリの単調増加がひどい

• https://gist.github.com/kjunichi/40d7c56697a7abea48ae

mrubyのエラーハンドリングさぼっていると、何が起きてるのか分からないことがある。 例えば、必要なmrbgemsがビルドされていないケースなど。

学習したこと

• trusterdは最近のものはrootで動かせない。
• 設定ファイルでユーザーを指定することで動いた

メモリリークの調査

valgrindを使った。

UNIXのプロセス関連の知識

• 子プロセスが終了すると親プロセスにその旨のシグナルが通知される。
• 明示的にこのシグナルの扱いを宣言していないと、keventで-1が返され、割り込みの発生を通知される。

Link

• mruby