今日は、ちょっと技術的な話で。
Linuxが動いているSTB上でF-Orcを
動かして、色々とテストしてるわけですが、
前々から、F-Orcのプログラム内でスレッドを起動したときに、
Linux上では、PIDが振られたプロセスとして見えていることにちょっと疑問を
抱いていたのだが、
そのことを以前ググッた結果、どこかの個人サイトで
「Linux上でのJVMのスレッドはそういう実装なんです。プロセスとして見えるんです。」
みたいなものを見つけて。
「ふーん。そんなもんなのか。」とあまり気にしてなかったのだが。
最近、MIPSのSTB上でJava SE Embeddedのテストをしている中で、
JVMのバグらしきものを発見し、
それが原因でF-Orcが正常に動作しない。という現象に悩まされていた。
これが解決しないと、JavaOneで見せる予定のデモができない。。。
今使っている、Java SE EmbeddedのVMは一応プレリリース版という
扱いで、まだPublicに公開していないもので、うち向けに
特別早く出荷してもらっているので、ある程度は仕方ないのだが。
そうはいっても、直らないと困るので、そのVMベンダーに調査依頼をかけたところ、
「We can't cause that Error.」と言われ、
仕方ないので、こっちで、エラーを起こす再現PGを送ったり、
今週、色々と調べてました。
で、テストPG実行時のstraceコマンドの結果を送ってくれと言われたので、
取っていたのだが、どうもスレッド起動した後の箇所でうまく取れない。。。
-f オプションで、fork後もtraceできるはずなのに、なんかうまくいかない。
別プロセスからattachさせれば、追えるのだが、
U.S.ではそんなことしなくても追えるらしく、
もしかして、うちの環境で動いてるLinuxのスレッドとプロセスのところが
あやしんじゃないか?と思い、色々と調べた次第です。
その結果、Linuxではスレッドをプロセスの子プロセスとして
実装しており、forkではなく、cloneというシステムコールを
内部で呼んでいるらしい。
正確には、ここのページに説明ありました。(IBM VMの説明だが、一緒だと思う)
結果的に、STBで起きたissueとこのスレッド&プロセスの件は、関係ないことが分かったのだが、
一つ疑問がスッキリしたなぁ。
因みに、STBのErrorは、「VMのバグでした。これから直します。」
という回答が今日U.S.から来ました(^.^)
0 件のコメント:
コメントを投稿