まぁ、Twitter で言われたように、
＊ exit する前に free() する
ってなのが積み重なって、こういうことになっている。僕は、もちろん free() しない派ですが…
でも、
＊ exit する前に、すべての thread を終了させる
だったらどうか? つうか、仕事はすべて終わっているんですかね?
OS の課題で、thread pool をちゃんと終了させるってのを出したら全滅だったっけ。
終了が問題になるのは、通信とファイルシステムですけど、通信は切れるの前提だし、ファイルシステムも最近は Journaling だから、途中で切っても被害は少ない。
なので、free() も thread の終了も確認しないで終わって良いわけなんだけど。実際、exit(0) すれば、malloc() されたメモリも起動した thread もすべて解放されるわけだし。
ただ、I-TRON は、そうではないってな話があった。thread を殺すと memory leak する。誰だよ、そんな仕様にしたのは… プロセスでは、そういうことはないんだけど。
どうも規範的な意味で「free() するべし」と言っている人がいるらしい。テストしようと思うと、free() も Thread の停止も必要になる。なので、コード的に入れるのはありだ。だが、実際の exit 時にそれをやるのは迷惑なだけだ。
一方で、exit() 時には free() / thread の停止を skip するコードを入れるってのは、若干抵抗はある。
これは、本来はコンパイラが取り除くべきものなんじゃないかって気もするが、malloc() や join() の詳細をコンパイラが知ることはありえないので、できないです。プロセス実行で将来 write がないなら、そこで終了みたいな最適化をしないといけないのか。
print 文忘れたら、最適化でプログラムが空になったとか、もっともよく使われているコードを専用命令化したら、OSのidle loopだったとか、そんな話に似てる。
意外に深い問題ではあるな〜
No comments:
Post a Comment