Bug #270
closed
lazy timer thraed creation
Description
=begin
ささだです．
現在，1.9 では timer thread というものを起動時に作って，以下の用途
に利用しています．
a) スレッドスイッチの契機
b) signal の集約
c) sampling profiling
(a) は SIGVTALRM の代わりに，select で polling して，定期的に ruby
threads に対してスレッド切り替えを促します．
(b) は，一度 signal を timer thread に集約して，その後 ruby thread
に signal の情報を渡すように実装しています．
(c) は，あまり活用されていませんが，sampling profiler として利用す
ることができます．今後の拡張用です．
ただ，最近のFreeBSDやNetBSDは，一度 pthread を作ると，後始末をして
も fork 後，pthread を作ろうとすると刺さるので，必ず timer thread を
作る 1.9 では fork が出来ません．そこで，最初に Thread.new するま
で，つまり，マルチスレッド実行を行うまで timer thread の遅延を遅らせ
るような提案を受けています．
(b) に関しては実装についてケアが必要で（これまで，ruby thread で
signal を受ける心配をする必要がなかった），(c) についてはあきらめな
ければなりませんが，FreeBSD, NetBSD などの広く利用されている OS で
fork が動かないのはまずかろう，という意見です．
fork をこれ以上使うな，という意見もあるかとは思いますが，この提案
については前向きに検討していきます．
忘れないように redmine に登録しておきます．
ご意見募集中です．¶
// SASADA Koichi at atdot dot net
=end
Updated by 
Updated by
Updated by naruse (Yui NARUSE) almost 15 years ago
- Status changed from Open to Closed
- ruby -v set to ruby 1.8.8dev (2010-01-17 revision 26335) [i386-netbsdelf5.0.1]
=begin
本件ですが、まず FreeBSD 7.2 あたり、NetBSD 5.0 あたりで OS 側に対処が入り、
pthread を使った後で fork しても刺さらないようになったようです。
(誰かコミットの特定よろしく)
また、関連する #2603 r26371 から得られた知見を追記すると、
01:04 (unak) 今日のまとめ
01:05 (unak) NetBSDのpthread_atfork()やばい
01:05 (unak) というか、pthread_atfork()の中でpthread_create()しちゃいけないんだろうね。
01:06 (unak) ああ、もう一個あった。
01:07 (unak) NetBSDだとfork()前に余分なスレッドを殺しておくのが吉... ... ...
01:44 (unak) parent handerでpthread_create()が呼ぶと刺さるのはなんか変なので、これはOS側で対応してほしいね。
ということになるようです。
=end
Updated by usa (Usaku NAKAMURA) almost 15 years ago
=begin
こんにちは、なかむら(う)です。
In message "[ruby-dev:40127] Re: Bug #270 lazy timer thraed creation"
on Jan.22,2010 08:54:15, kosaki.motohiro@jp.fujitsu.com wrote:
僕の知見は
pthread_atfork(0, 0, rb_thread_stop_timer); はダメな子
につきるような。この子が意味があるプラットフォーム、あるんだろうか・・・
ですよねー。
子プロセス側ではtimer threadは死んでるに決まってるんだし...
それでは。¶
U.Nakamura usa@garbagecollect.jp
=end