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

けいじゅ＠日本ラショナルソフトウェアです.

In [ruby-dev :12414 ] the message: "[ruby-dev:12414] Re: fork in
threads ", on Mar/10 22:59(JST) Masatoshi SEKI writes:

>咳といいます。

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

だとおもいます. 問題は, ライブラリ側で陰でこそこそやっていることは, ユー
ザ側にはわからないってことでしょう.

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

UNIXのforkが現状のRubyのセマンティクスかっていえば, そうでもないってのが
POSIXのforkでは?

あと, UNIX forkでも, 親プロセスと子プロセスはまったくのコピーではないで
すよね. たとえば, forkすると親プロセスの子プロセスは子プロセスに引き継が
れませんよね. あたりまえって言えばあたりまえですが, これをスレッドに言い
直して, forkすると親プロセスのスレッドが子プロセスのスレッドに引き継がれ
ないとなってもそれほどおかしくはないでしょう.

>でした。これに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
>
>というのとか。

まず, (1.2)が実現できるのか, Thread.remain ですかね. 

(1.5)がユーザ側ではライブラリ側がかってに起こしているthreadをkillすべき
かどうかかわからないってのが問題でしょう. まだ, IOだけなならユーザ側が管
理している場合が多いのでどうにかなると思いますが.

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

生fork(sysforkかな?)は, あっても良い気がしていますが, あることによって何
が利点か? というか何が実現できなくなるのかが見えないです. その機能がなく
ては困るって状況がない限りないほうがよいのでは? と感じています.

たぶん, POSIX forkがそうなんだから, なくてもどうにかなるのでは?  と思っ
ています.

__
..............................石塚 圭樹＠日本ラショナルソフトウェア...
----------------------------------->> e-mail: [e-mail] <<---