技術メモ(その6)

今回はいくつか用語について説明します。
間違っていたらコメントで指摘してください。



まずRTCをexitではなくプロセスを強制終了したりするとゾンビが出てきますが、これがどういう状態なのか説明します。
まずRTCは起動時にネームサーバーにオブジェクトの参照を登録します。
この参照を使ってRTCの各種操作ができるようになるわけですが、当然のことながらRTCのプロセスが消えると操作はできなくなります。
これで参照だけは消えずに残っている状態がゾンビという事にはなると思います。
要はこの図のサーバーが消えた状態です。
ただプロセスが終了した以外にもファイアーウォール等で通信できなくなっている状態もあるかもしれないです。





マスターマネージャ、スレーブマネージャについて説明します。

まずマネージャは基本的に1つのプロセスで1つ起動されるわけですが、大きく分けて以下の3つの状態で起動するのだとは思います。

1. マスターマネージャとして起動
2. スレーブマネージャとして起動(登録するマスターマネージャが存在する)
3. スレーブマネージャとして起動(登録するマスターマネージャが存在しない)

まず1ですが、マスターマネージャとして起動する事でcorbaloc形式、もしくはネームサーバーからマネージャのオブジェクトリファレンスを取得することができます。マネージャのオブジェクトリファレンスを取得するコードは以前の記事の通りです。

2ですが、登録するマスターマネージャが存在する場合は起動時に自動的にマスターマネージャにスレーブマネージャのオブジェクトリファレンスを登録します。スレーブマネージャはマスターマネージャのオブジェクトリファレンスからget_slave_managers関数を使えば取得できます。つまりマスターマネージャからスレーブマネージャを操作できるようになります。

3ですが、マネージャを外部から操作する事はできなくなります。





修正されているのかどうかは知りませんが、RTシステムエディタでマスターマネージャを選択すると固まります。
マネージャのget_loadable_modules関数でロード可能なモジュールを取得しようとする時に発生するみたいです。
まずrtc.confでどのような設定をしているかにもよりますが、C++はrtcprof.exe、Pythonはrtcprof_python.bat、Javaはrtcprof_java.batでRTCのプロファイル(ソースコードの～_specの部分)を読み込みます。

そもそもrtcprof.exe、rtcprof_python.bat(rtcprof.py)、rtcprof_java.bat(rtcprof.jar)を使うとどうなるかと言うと、

> rtcprof test.dll

implementation_id: test

type_name: test

description: test Component

version: 1.0

vendor: Sample

category: Sample

activity_type: PERIODIC

kind: DataFlowComponent

max_instance: 0

language: C++

lang_type: compile

こんな感じでプロファイルが出力されます。
要するにC++版のOpenRTM-aistのマネージャではrtcprof.exe、rtcprof_python.bat、rtcprof_java.batを実行して出力を受け取ることで各言語のRTCのプロファイルを取得できるわけですが、この時にRTシステムエディタが固まることもあるらしい。

まずRTCではないDLLがモジュールの探索パスに存在する場合に少し固まりますが、これは別に大して気にならないと思います。

ただrtcprof_python.batはプロファイルを出力してもプロセスが終了しないらしく、ここで固まって動かなくなります。しかもおそらくrtc.confはプロセスを起動したディレクトリのものを読み込むので、manager.is_masterがYESになっているかmanager.shutdown_autoがNOになっていれば永久に終わらないという事になります。
一応ですがrtcprof.pyのマネージャ初期化直後にマネージャの終了処理をすればプロセスは終了するのでそうしてください。

  OpenRTM_aist.Manager.init(opts)

  mgr = OpenRTM_aist.Manager.instance()

  mgr.shutdown()　　　←追加

ここでマネージャの終了処理をしても特に問題はないようです。

(追記)上の方法は根本的な解決にはなっていないような気がするので、気になる人はC:\Python27\Lib\site-packages\OpenRTM_aistあたりにあるManager.pyを編集してください。


self._timer = OpenRTM_aist.Timer(tm)
self._timer._thread.setDaemon(True)　　←追加
self._timer.start()






ただPythonのOpenRTM-aistでマネージャを起動してもこの現象は起きません。
Python版ではrtcprof.pyを使っておらず、ModuleManagerの__getRtcProfile関数で処理しているので問題ないようです。
なのでPython版でrtc.confのmanager.modules.<lang>.suffixesやmanager.modules.<lang>.profile_cmdは設定しても全く意味がないみたいです。






あまり知られていない機能だと思いますが、マネージャのcreate_component関数で、




test&manager=localhost:2810(コンポーネント名&manager=マスターマネージャのアドレス:ポート番号)




のような形式で入力すると指定したマスターマネージャ上でRTCを起動してくれます。
指定したマスターマネージャが起動していない場合は新たにプロセスを起動してくれるみたいです。
ただ、一体何が正しい動作なのかがよく分かっていません。
ManagerServant.cppのマスターマネージャ起動のところのソースコードを見てみると、

std::string cmd("rtcd -p ");
cmd += mgrvstr[1];
int ret(coil::launch_shell(cmd.c_str()));


となっているのでrtc.confはプロセスを起動したディレクトリのものを読み込むことになると思います。つまりそのrtc.confでマスターマネージャを起動するように設定していなければマスターマネージャは起動する事はありません。

何が正しい使い方なのかは謎ですが、使う機会もあるかもしれないので豆知識程度に覚えておいてもいいかもしれないです。














にほんブログ村のロボットのカテゴリから
全然人が来ない・・・

•