#ふーむ、Kahuaは現役で動かしてるサイトがあるんで本体は最新Gaucheで動いてるはずなんですが、sampleの方はチェックしてなかったな。
#絶賛放置中のメンテナです。www.kahua.org、電源が入っていないみたいなので後で確認してきます(マシンルームにある)。これ、そろそろどっかのクラウドなりVPSに移したいなぁ。
#過去のいきさつから、わたしの勤務先がホスティングしてるんですが、会社がからむといろいろ面倒くさくて。本音では個人で引き取っちゃいたい。
#ぜひDocker+CoreOSで＞kahua.org
#それ何がおいしいか今度教えて下さい。
#CoreOSはChromeOSと同じで2パーティションで自動アップデート。Dockerは計量コンテナ。image作っちゃえば何台でもデプロイできる。CoreOSはパッケージシステムがDocker。
##nene.kahua.orgは上がっている
#whois ns1.kahua.org するとNOT FOUNDと言われる
#レジストラ上のネームサーバ登録が消えてるのか。何でやねん。
#ns1.kahua.org: 218.225.123.186
#コミュニティ向けにインフラ提供してくれるConoHa支援プログラム https://www.conoha.jp/community とかあるみたいですよ。クラウドなりVPS移行なら。事前審査ありますけど。> kahua.orgの件 #ありがとうございます。
#特定のスポンサーを付ける場合、スポンサーがコケると移転を迫られたりするのでいろいろ難しいです。
#経緯あってtuduraまだ使ってる.
#ドメインの更新に失敗していた模様。whoisだとちゃんと更新されているように見えるのに、レジストラの管理画面ではexpireしていたという。どういうこっちゃ。
#どっかキリ良いところでissueもgithubに移せばいいんだがイシュー番号がすでにアレしててトピックブランチもイシュー番号でアレしててうんぬんかんぬん
#ドメインの管理者に更新を依頼しました。
#exporterとimporter書くしか
#イシューを持ち運ぶ必要性はあまりないっちゃないかなー。
#単にトピックブランチをi0123みたいに付けてて、今からgithubで番号取るとするとどういうブランチ名にしようかなーとかその程度なんですわ.
#まぁ、移行後は古いのを参照だけできればいいんだろうけどね。
#この割り切り方ならCoreOSいいかも。docker依存すぎかもしれんけど。
#サービスにフォーカスするなら、ちまちまOSいじって環境作る時代じゃないってことですね。
#環境作るのはその時一回限りならいいんだけど、結局そういうわけにはいかないですからね。私もそろそろ自分の管理しているやつを時代に合わせないと…
#www.kahua.orgはいろいろと化石化しているので、いい加減リプレイスしないと。マシンルームから追い出して、外に置きたいですね...
#リポジトリはgithubに移したんだから、githubに移しちゃえばいいんだろうけど
#kahua.org 復活しました
#ありがとうございます！ こんなにすぐに対応していただけるとは・・・Gaucheコミュニティあなどってました（笑）
#KahuaのプロジェクトページをGithub Pagesにしちゃうってこと? それでもいいかも。
#kahua-package generateのエラーって、kahua-configが設定されないと必然的に出ちゃうんだけど、generateで最初にプロジェクト作るときのデフォルトのconfigってどっから引っ張ってくるんだったっけ?
#完全に忘れてますね...
#twitter で見かけた make check が system で止まる件ですが，手元の ubuntu で夜中に回していたら再現しました．
#test.log の最後の出力は以下の 2 pattern があった.
1) test fork & sigint, expects #t ==>
2) test sigmask, expects hup ==>
1) の場合, zombie 子プロセスがいる場合といない場合があった (各 1 sample).
2) の場合は zombie 子プロセスがいた(1 sample).
enami 22007 22002 0 10:33 pts/1 00:00:05 ./gosh -ftest -I../test syst
enami 22081 22007 0 10:33 pts/1 00:00:00 [gosh] <defunct>
2) の場合は strace をしていた. signal を送信しているあたりは以下のとおり.
22007 clone( <unfinished ...>
22009 futex(0x7f277a402600, FUTEX_WAKE_PRIVATE, 1 <unfinished ...>
22010 <... futex resumed> ) = 0
22009 <... futex resumed> ) = 1
22081 set_robust_list(0x7f277a706a20, 24) = 0
22010 futex(0x7f277a402600, FUTEX_WAKE_PRIVATE, 1 <unfinished ...>
22009 futex(0x7f277a402584, FUTEX_WAIT_PRIVATE, 406, NULL <unfinished ...>
22007 <... clone resumed> child_stack=0, flags=CLONE_CHILD_CLEARTID|CLONE_CHILD_SETTID|SIGCHLD, child_tidptr=0x7f277a706a10) = 22081
22010 <... futex resumed> ) = 0
22010 futex(0x7f277a402584, FUTEX_WAIT_PRIVATE, 407, NULL <unfinished ...>
22007 nanosleep({0, 200000000}, <unfinished ...>
22081 getppid() = 22007
22081 kill(22007, SIGINT <unfinished ...>
22008 <... futex resumed> ) = ? ERESTARTSYS (To be restarted if SA_RESTART is set)
22008 --- SIGINT {si_signo=SIGINT, si_code=SI_USER, si_pid=22081, si_uid=1000} ---
22008 rt_sigreturn() = -1 EINTR (Interrupted system call)
22008 futex(0x7f277a402584, FUTEX_WAIT_PRIVATE, 407, NULL <unfinished ...>
22081 <... kill resumed> ) = 0
22081 nanosleep({0, 200000000}, <unfinished ...>
22007 <... nanosleep resumed> 0x7ffffcf10360) = 0
22081 <... nanosleep resumed> 0x7ffffcf10360) = 0
22007 nanosleep({0, 200000000}, <unfinished ...>
22081 getppid() = 22007
22081 kill(22007, SIGHUP) = 0
22081 exit_group(0) = ?
22081 +++ exited with 0 +++
22008 <... futex resumed> ) = ? ERESTARTSYS (To be restarted if SA_RESTART is set)
22008 --- SIGHUP {si_signo=SIGHUP, si_code=SI_USER, si_p#22081から
#1) の場合はたしかにテストコードに race があって，その競合具合によって子プロセスが残る場合と残らない場合に分かれそうです．2) の場合は別なスレッドに signal が配送されたことによって，想定と違う動作になったのではないかと思います．
#22081から22007にシグナルを送ってるのに22008でそれを受けてるように見えるのはなぜだろう。もちろんNPTLですよね。
#ubuntu 14.04 です
#さすがにいまどきLinuxThreadってことはないはずだよなあ。すると22008ってどこから来たんだろう。
#このスレッド，すごく初期の段階でつくられていて，おそらく gc の parallel marker だと思います．
#あっそうか、そこがmaskしてないとシグナル受けちゃうんだな。
#そういうことだと思います．
#gcでスレッド間同期に使うシグナルはmaskできないけど、他のはmaskしとかないと、Gaucheに限らずシグナルを使うプログラムではもろ鬼門になるような。
#本家でも問題になってたりしないんでしょうかね．
#本家MLを探してみたけど、とりたててこの問題が持ち出された例は見つからなかった。でもそもそもgc使うならシグナルハンドラでできることは極めて制限されていて、それを守っている限り普通は問題にならないのかも (gcスレッドからシグナルハンドラが呼ばれて、その後gc続行)。今回問題になったのは「他のスレッドでシグナルブロックしてるはずだからこのnanosleepがEINTRで中断されるはず」ということを当てにしていたからで。
#Gaucheのシグナルハンドラの使い方を考えると、GC_init自体をシグナルマスクつきで呼んで、gc関連スレッドに(gc用シグナル以外の)非同期シグナルを一切渡さないようにするのが吉だな。
#むー、GC_INITが最初にどこから呼ばれるか確定できないから、boehm gcの方に手を入れないとだめかな。
#libgauche の立場からすると，ってことですか．signal は process wide な資源なので，実行ファイル作る人が最終的には面倒みないといけないでしょうね．
#一般的な話として、本来、GC_INITをmainから呼ばないとポータブルではないんですが、ほとんどのプラットフォームでは呼んでなくても最初のGC_* APIコール時に自動的に初期化されて問題なく動くようになってて、その場合アプリ側から見るといつ初期化されるのかわからないからGC_set_sigmaskみたいなAPIをbdwgcに作っといて初期化時のマスクを指定出来るようになってたら良いかな、という意図です。
#まあ、「mainで必ずsigmaskセットしてGC_INIT呼んでね」という約束にしておけば要らないんですが。
#そういうことをするSCM_INITを用意しておけばいいのか。
#現状の gauche の仕組みだと管理下にないスレッドで sig_handle() が呼ばれてしまうとシグナルロストするので，そういう約束なり 3rd party library 毎の対応は必要ってことですね．
#Gaucheの知らぬところでスレッド作られてしまうとどうしようもないので、それはそういう約束にするしかないですね…元はと言えばUnixのシグナルの設計が十分にモジュラーになってないのが悪いんや…
#待てよ、libgaucheが設定したシグナルハンドラが呼ばれて、しかしそのスレッドにGauche VMが無かった場合、「自スレッドでそのシグナルをブロックしてから自分自身に同じシグナルを送る」という手は使えるだろうか。
#他所のスレッドで勝手にマスクを変えるのは気持ち悪いけれど、libgaucheのハンドラが呼ばれてるってことはそっちのモジュールでそのシグナルをハンドルする意図は無いってことだからぎりぎりセーフな気もする。
#(上の自分自身→自プロセス、という意図。いずれGauche VMを持つスレッドにシグナルが渡る。)
#やったことないけど，signal() は async signal safe みたいですね．pthread_sigmask はどうなんだろう．（いつのかわからない）glibc のと netbsd の実装は大丈夫そうだけど．
Gauche > Archives > 2014/10/01