うげー、よく今まで平気だったなー
今度からはまめに掃除しよう
まず、田中さんのサンプルプログラム、よくみると、getcontext()している関数中でローカル変数がvolatileされていない。
んで、さらに困ったことにsetjmp()はC99（JISだとJIS X 3010）の規格で
「ただし対応するsetjmpマクロの呼び出しを含む関数中の、volatile修飾型でない自動記憶域期間をもつオブジェクトの値が、setjmp呼び出しとlongjmp呼び出しの間に変更された場合に不定となる事をのぞく」
と但し書きがあるので、こういうコードは書けない。
※ JISCのサイトで規格が無料で読めるので興味のある人はドゾ
スキャナで取り込んだと思しき、全ページ画像のクソPDFなので、検索できなくて超使いにくいけどね（苦笑）
んで、困ったことにSingle UNIX Spesification(SUS)のgetcontextの定義ではこのvolatile云々の免罪事項がないらしいんだわ。
※２ Linuxの人は man 3p getcontext で規格定義が読めるらしいよ。便利な世の中になったね♪
でも、この volatile 云々ってのはThe rationale for the C99 standard に書かれているように、そもそも変数がレジスタに乗るかどうかコンパイラしか知らない状況ではライブラリに出来る事なんかねーよハゲ。って事なので、書いてないからvolatileなくても動くように作れよ。と言われてもなかなかツライものがあるのである。
たぶん、唯一の解決策は、setjmp, getcontext呼び出しを含む関数はすべてのローカル変数をvolatileであるかのように扱う。ってやつでgccがやっている対策もコレ（のはず、よく知らないけど）
でも、やっぱりオイラは規格を直すべきだとオモタですよ
定義不能！ ランキング！
教訓。
下調べ重要 ← アタリマエ
これってPOSIX違反じゃねーの？
とかオモタ
何でかって言うと、
１．POSIX的にexecすると、exec呼び出しスレッド以外のスレッドは
すべて死ぬ
２．LinuxにおいてプロセスID＝メインスレッドのスレッドIDである
３．１，２とつじつまを合わせるため、exec時に自分がメインスレッド
でなかったらプロセスIDを自分のスレッドIDに設定しなおす
という動作をしているため。
（´_ゝ｀）フーン ...
ここは一つ、現代にあわせて貴族とチェコ人と言ってはどうか？
と思ったが、貴族といっている時点で全然現代的ではない。
アメリカ人とチェコ人？
しかし、それだと何だか意味不明である。
だいたい、本義的な意味じゃなくて、一般的なボヘミアンというのはチェコ人じゃなくてジプシーの事で、フランスあたりでジプシーが
オイラ、ボヘミアの方から来たよ。まじまじ。
などと言いながら乞食生活をしたのが始まりらしいから。
アメリカ人とジプシー？
だぁ！
そんな危ない用語、使えるか！！
（＊）神聖ローマ帝国に加入しているので選帝権あるぞ。一度も行使できなかったらしいが。
RELAX Wins
Choose RELAX Now
(XML Schemaではなく)RELAX NGを使おう、という勝利宣言。数多くのアプリケーションで実際に使われているだけでなく、規格という点からもISO/IEC 19757, Part 2に含まれたRELAX NGに劣るところはない、そうだ。
私自身はXMLの事情について詳しくはないが、少なくともボヘミアンと貴族の闘争でとうとうボヘミアンが勝ったということは感慨深い。
むむ、Rubyのまつもとさんという（こう言ってはなんだが）XMLとはあんまり縁の無さそうな人からこういう記事が出てくるのは興味深い。
元某秘密結社の団員として。
（実は何が秘密だったのだかいまだによく分からないのだが、秘密結社のプレゼンを当時の社長に見られて、うろんな目で見られたことだけは克明に覚えている）
規格をあーだこーだ言っていた時には、James Clarkの提案する無茶な仕様に関係者みんなで「どひー」とか言っていたものだが、好評なんやー。とかとか
まあ、そんな戯言はさておき。
実は一番気になったのはリンク先の
Finally libxml, Linux’s standard XML parser, includes full support for RELAX NG, but only partial and incomplete support for W3C schemas.
という文言なのだが、いつfull support したんかいね？
オイラてっきり一生フルサポートはしない（出来ない）と思ってたよ。
どうでもいいけど、このブログは誰に書いてるんでしょね？
誰にも分からない話題満載(^-^;;
それはさておき、飲み会がしたいなぁーー
秘密結社！ ランキング！
困ったものだ。
＃こんなサイトにお望みの情報はありません(^-^;;
親プロセス以外が、プロセスの終了を通知してもらう方法はあるのか？
という話。
最初に聞いたとき、脊髄反射的に、いろいろあるよーーー。と思った
do_exit()を追うだけでも、
profile_task_exit()
profile_handoff_task()
proc_exit_connector()
security_task_free()
このぐらい見つかる。
んが、どいつもこいつも、task_struct終了時通知なので、スレッドが死ぬ度に通知が飛びやがるのである。
しかもexit処理はいくつも同時に走りうるので、通知関数で
thread_group_empty()やら tsk->signal->live==1 やらでチェックするのもウマくない
（チェックしている最中にどんどん状態が変わるから）
さて、どうしたものか
P.S
ところで、netlinkのプロセスの生成・終了を監視する機構って全然ドキュメントないんだけど、誰が何のためにいれたんでしょ？？
需要があるかどうか分からんけど、今度手引書書こうかしらん
追記
待てよ・・・
profile_handoff_task()
security_task_free()
の２つは put_task_struct()から呼ばれているのだからして、
thread_group_leaderは必ず最後にPF_DEADに遷移する。の規則により
この２つでif(pid==tgid) と判定するだけかぁ？？
今度試す。
追記２
KAMEさんから、すごく素朴な指摘をうけて、ああ、説明が足りんかったと反省。
もっと具体的に書く。
あるプロセスにスレッドが２ついたとする、それぞれのpid, tgidは以下
pid tgid
--------------------------
スレッドA 101 101
スレッドB 102 101
そうすると、上記Hookはプロセス終了時に2回呼ばれる（スレッドが2つあるから）
ところが、たとえば、profile_task_exit() でprintkデバッグしていると以下の２つのケースがありうる。
ケース１）
１．スレッドA profile_task_exit()
この時、tsk->signal->live==2
２．スレッドB profile_task_exit()
この時、tsk->signal->live==1
ケース２）
１．スレッドA profile_task_exit()
この時、tsk->signal->live==2
２．スレッドB profile_task_exit()
この時、tsk->signal->live==2
ケース２で何が起こっているかというと
１．スレッドA profile_task_exit()
この時、tsk->signal->live==2
２．スレッドB profile_task_exit()
この時、tsk->signal->live==2
３．スレッドA atomic_dec(tsk->signal->live)
４．スレッドB atomic_dec(tsk->signal->live)
のように、do_exit()が２つのスレッドでほぼ同時に呼ばれる事により、
（このような状態はdo_group_exit()を呼ぶだけで簡単に作り出せる）
Hook関数からは、signal->liveの参照カウンタが2->2->0と変化したかのようにみえてしまっている。と。
んで、POSIX的にはmain thread に対してpthread_exit()を呼ぶことはアリなので、そうするとmain threadが最初にdo_exit()で抜けてくるやもしれず、pid==tgidでは判定できず、かつ、参照カウンタも信用できず。うーむ。
というのがそもそもの悩みだったのですよ。
監視プロセスが１つだけなら、ユーザーランドからkill -0 で定期監視すればいいけど、おいらが作っているのはミドルウェアで、監視対象が１００とか１００００とか増えてくると定期監視はいまいちヤル気がしないというのもあって、カーネルから通知してくれる口はないものかしら。と思っていた。と
そういうわです。
分かりにくくてすいませんm(_ _)m
＃しかし、うちの近所の本屋は漫画の入荷が遅くていかんわ。あっという間に周回遅れになってしまう。
作中に出てきたクヌート王子はやっぱりクヌート大王だったりするのだろうか？
トルフィンを匿ったうちのお嬢さんがレイプされてたりするのがお茶目。
どうでもいいけど、昔だれかがトルフィンの家系図公開してたの思い出した。
ので、一生懸命検索してた。こういうのって後から探すと本当に見つからない。
と、思ったら、鮎方さんの所だった。灯台下暗し
http://d.hatena.ne.jp/Ayukata/10010120
始めにオーディンあり。フリッグと結ばれる（共に北欧神話より）。
その子は（伝承上の）デーン王スキョル。
（中略）
その子はスウェーデン王“指輪の”シグルド。アルフハイム出身の、ガンドルフ*2の娘アルフヒルドと結ばれる。
（中略）
その子はスノーリ。トールヒルドと結ばれる。
その子はトールズ。
その子はトルフィン・カールセフニ。970年に生まれる。赤毛のエリクの義娘グドリッドと結ばれる。人を率いてヴィンランドへ移住する。
おおー
オーディンから始まって、デーン王、スウェーデン王とそうそうたるメンバーですな。
あっと、一応補足しておくと、上記サイトは別に漫画の同人設定をでっち上げてるサイトではなくて、実在するトルフィンの子孫（を自称する人）の家系図の転載しているわけですね。
↑むかし、真面目にPDFを読もうとしてノルウェー語に完敗した人
型的には void* であってはいけないはず。標準のドラフトによると、
-4- The macro NULL is an implementation-defined C++ null pointer constant in
this International Standard (conv.ptr).*
[Footnote: Possible definitions include 0 and 0L, but not (void*)0. --- end
foonote]
だと。つまり 64bit でも NULL 使えば問題は起きないんだろうね。可変長引数のみ NULL 使って他は 0 使っておくのが無難って感じだろうか。
そういえば、昔、規格書PDFを買ったような・・・
と遠い記憶をたよりにごそごそと。
んで、出てきたのがこれ。
んーまあ、ほとんど変わってないね
オイラが見ている規格バージョンは以下ね
ISO/IEC14882 Second edition 2003-10-15
（Shinhさんの見てるのはいつのだ？？）
関係しそうなところをいくつか抜粋
4.10 Pointer conversions [conv.ptr]
1 A null pointer constant is an integral constant expression (5.19) rvalue of integer type that evaluates to
zero. A null pointer constant can be converted to a pointer type; the result is the null pointer value of that
type and is distinguishable from every other value of pointer to object or pointer to function type. Two null
pointer values of the same type shall compare equal. The conversion of a null pointer constant to a pointer
to cv-qualified type is a single conversion, and not the sequence of a pointer conversion followed by a qualification
conversion (4.4).
18.1 Types
4 The macro NULL is an implementation-defined C + + null pointer constant in this International Standard
(4.10).180)
Annecx C(informative) Compativility
C.2.2.3 Macro NULL [diff.null]
1 The macro NULL, defined in any of <clocale>, <cstddef>, <cstdio>, <cstdlib>, <cstring>,
<ctime>, or <cwchar>, is an implementation-defined C + + null pointer constant in this International
Standard (18.1).
こうしてみると、null pointer は任意のポインタに変換できるintegral constant expressionと明記してあるので、intへの代入で警告を出すgccはグレーゾーンかも分からんね
（超便利なので否定する気はまったくないが）
追記：
ちなみに、
C++は型チェックが厳しいので、どのNULLマクロよりもただの０を使ったほうが問題が少ないと書いてあり、その下にオススメのNULL定義として
const int NULL = 0;
があげられています(-_-;
＃まあ、あの本は先生の趣味で書いた本であって、実用を考えた本ではないらしいから。。
後輩とかにぜひ読ませたかったので、満足。
会社でも同人誌って買えるのね(^-^)
もっとオカタイ会社かと思ってたよ
http://d.hatena.ne.jp/yupo5656/20040624/p1
"2" は巷で "strict non-overcommit mode" などとhref="http://linux.derkeiler.com/Mailing-Lists/Kernel/2003-11/4047.html">呼ばれているもので、全プロセスの現在の合計malloc量をkernelが覚えているモードだ。さらに、そのmalloc量の上限を
/proc/sys/vm/overcommit_ratio で設定できる。具体的には次の単純な数式だ。malloc_limit[MB]
= swap領域のサイズ[MB] + (物理メモリ量[MB] * overcommit_ratio / 100)まとめ
今まで述べた事柄により、メモリが逼迫した状況でも、memory overcommit
によるプロセスの突然死を起こしたくない状況では、/proc/sys/vm/overcommit_memory を "2" にし、かつ
overcommit_ratio を調整して "malloc_limit"値 が物理メモリ量を超えないようにすれば良い
という結論が導かれる。swapを持たない組み込み機器などでは、単純にovercommit_ratio を100に近い値にしておけば良い筈。
んー、overcommit_ratioを100に近い数字にするのはお勧めできません。
まず、Linuxにおいて、overcommit管理機構において、管理されるメモリ、されないメモリについて説明しましょう。
端的に言うと、brkとmmapのMAP_PRIVATEで確保されたメモリのみがカウントされます。
つまり・・
＜＜カウントされる＞＞
・データセグメント（Ｃ言語のグローバル変数が格納されている場所）
・ヒープ（mallocでとる場所）
・スタック
＜＜カウントされない＞＞
・テキストセグメント
・MMUが使うメモリ
・kernelが使う各種メモリ
・バッファーキャッシュ・ページキャッシュ
・tmpfsが使うメモリ
となります。
結構、カウント外が多いので要注意なのですよ。
カーネル関係はわかるけど、テキストセグメントがカウントされてないのは納得いかないって人もいると思うけど、read-only mappingのデータはswap outさせずに単純にメモリから捨てればいいので、カウント外、という思想みたい。
こんだけカウント外が多いと、巷で言われているようには全然「strict non-overcommit mode」なんかでは全然なく、こいつを設定していても、OOM killerで死ぬときは死にます。
ははは・・・・
あと、注意点をいくつか。
HPCではテキストセグメントのサイズなんでカスですが、普通のサーバーでは馬鹿にならない割合をしめますし、
イマドキの64bit CPUではMMUの管理構造は結構メモリを食います。
あとkernelが使うメモリは大半がたいした量ではありませんが、FS周りは結構食います（昔はext3が酷かったんだが今はどうなんでしょ？）
バッファーキャッシュはまあキャッシュなんで多少は融通利くのですが、これがある閾値以下になるとOS性能がみるみる劣化するのでまったく計算外には出来ない。
あと、一番忘れやすいのがtmpfs.tmpfsのFSサイズ分だけ、最初から物理RAMから控除して計算しておくことをオススメするっす。
こう考えると、デフォルトのovercommit_ratio=50% はちょっと小さめだけど、そんなに無茶苦茶じゃないというか・・・
んじゃ、どうやって計算するとええのん？
っては難しいので別稿にて（←それ未来への負債）
むしろ、0%(絶対にスワップ可能な量しか許さない）ってほうが分かりやすいかもしれんね。
とか考えたり考えなかったり・・・
まあいい。
別稿だ。別稿！ ←それ未(ry
P.S.
ulimit -m(RSSでlimit)はLinuxでは単純に未実装ですから。。 ←だれに言うとんのや
その他の参考記事一覧：
http://d.hatena.ne.jp/pekeq/20060601/p1
http://d.hatena.ne.jp/futsu-9/20060601/p2
http://d.hatena.ne.jp/futsu-9/20060617/p1
http://www.nminoru.jp/~nminoru/diary/2005/01.html
http://www.nminoru.jp/~nminoru/diary/2005/12.html
追記：
ごめん、見直したら、tmpfsはなんかちゃんとカウントしてるっぽげ。
これは追試テストをして、結果を書きます。
ちょっと調べた感じではよーわからんかった。
いや、なに。
うちのXさんは酷使すると、すぐswapに逃避する現実逃避野郎なので、
mlockall でも仕込んでやろうかと思いましてな。
逃げちゃだめだ、逃げちゃだめだ、逃げちゃだめだ。。
気づいた理由が現実逃避にゲームをやろうとしたから。というのは秘密だだだ
＃せっかくコサックス２買ってきたのに・・・
しかしアレだね。
パソコンが壊れるというのは、どうして、こうもwktkするかね。新しいのを買う言い訳を発見したというかｗｗ
最近読んだ本シリーズ
結局いいたいのは
・日本はアメリカにとって（地政学的に）超重要な同盟だからそうかんたんには、切られない。もっと無理いってもヘーキ
・自衛隊には敵国に兵力を投入する能力が徹底的に欠けているので、自力戦争は無理。だから日米同盟重要だし、ぎゃくに近隣諸国にはこの事を明確につたえて日本脅威論を排除すべき
の二点だけなのかとオモタ。
データとかがすくないので、それ以上は著者の感想にすぎず、あまり意味ないかもしれん。