[ruby-dev:12414] Re: fork in threads

咳といいます。

石塚さん:
> ということで, fork_and_kill_other_threads をforkの動作にすべきだと思いま
> す. また, thread単位に生き残るかどうかの指定ができる云々って話がありまし
> たが, threadが生きていて欲しいかどうかはthread単位の問題ではない気がしま
> す(だれがforkするかによって決まる). forkn()みたいな別の関数として用意す

ふむ。
「だれがforkするかによって決まる」っていうのはまったくそんな気が
してきました。スレッドや資源の性質によって決まるんじゃなくて、
なんのためにforkするかによって決まるんですよね。


なひさん:

> > 次に, ライブラリ側がthreadを用いていてそのライブラリをを用いるユーザ側が
> > forkしたい場合ですが, ユーザにとってforkしてもthreadが生きていなくてはな
> > らないって場合はないはずです. あったとしても, ライブラリ側でforkを必要な
> > 動作をするように再定義してあげればいいだけです. 
> 
> 「Rubyのforkを↑のように定義しよう。上のようなことをする機能を、
> forkと呼ぼう」というお話だと理解しました。であれば、
> そのようなforkをした時に、ライブラリの中で（外部には隠して）
> 利用しているスレッドが死んでしまい、正しい動作をしなくなる
> （例えばDRb）のは、まっとうだと思います。
> ユーザーが責任を持つべきです。

UNIXのfork()のイメージだとそっくりそのまま残る感じがしますけど、
きっとfork()の目的はある処理(スレッド)の環境を作るためにプロセスを
生成することなんでしょうね。そうするとそのスレッドだけしかない
プロセスが用意できた方がいいものなのかもしれませんね。


> ただし、
> 
> > それにユーザ側が, forkし
> > たら必ず必要ないthreadをkillしなくちゃ行けないってのは, 使いやすさに反し
> > ます.
> 
> もともとforkという機能が使いやすくないですから、
> 上記の主張にはあまり意味がないと思います。
> forkするならthread以外にも問題はいろいろあるので、
> 相応の覚悟が要りますよね。

fork()って難しいです。

手元のCのfork()するコード眺めてたのですけど、ほとんどのものが

  1. fork()
  2. 興味のないファイル記述子を全部close()
  3. 興味のない資源(あれば)を全部開放
  4. 前処理 (dupとか??)
  5. 本処理 (そこで処理の関数を呼ぶか、exec())

でした。これにThreadのkillが入るのはそんなに違和感ないかなー。

forkしたスレッドがメインスレッドになると仮定してRubyだったら‥

  0. tmp = Thread.criticla; Thread.critical = true
     IOのflush等
  1. fork()
   子
     2. forkしたスレッドがメインスレッドになる
     3. 興味のないIOのclose   # というか興味のあるIO以外のclose
     4. 資源の開放
     5. 興味のないThreadのkill  # 興味のあるThread以外のkill
     6. 本処理
  2. Thread.critical = tmp

というのとか。

popen()的な使い方だったら全自動killも現実的だと思います。
けど、生のfork()に近いものも残ってた方がUNIX的だと思うの
ですけどどうなんでしょう。

といっても咳はほとんどRubyでfork()使わないので見当違いかも
しれませんが。


> # 過激な提案
> # 1. dRubyをrubyのcoreに組み込む。

うーむ。つまんないようなうれしいようなつまんないような‥。