[openrtm-users 01482] Re: rtc_handle for OpenrtM-aist-1.0.0 （ほぼ完成か？）

2010年 11月 11日 (木) 09:20:17 JST

安藤です

>> 1.0をリリースするときに行ったメモリリークテストでは、データポート
>> サービスポートともにメモリリークは発見されていませんので、
>> （仕様に従って呼び出している限りは）たぶん大丈夫だと思います。
> この仕様に従っているというのが曲者です。仕様にしたがっているからと言ってメモリーリークがないわけでは
> ありません。その実装によると思います。

上の文章の意味は、下のDosygenのドキュメント上の（OMG RTCの方でなく、私が決めた）仕様に従って
connect()を呼び出している限りは、その仕様に従ってメモリリークテストをしており、
リークは検出されなかった、という事実を述べただけです。

Dosygenで書かれた仕様で想定されている以外の方法で（例えば変なConnectorProfileを
connect()に与えるなど）呼び出された場合は、リークするかもしれませんし、
最悪クラッシュするかもしれません。引数に与えられたConnectorProfileに不整合が
あった場合、極力検出してエラーにするなど対処はしているつもりですが、
それにも限界はあるので、仕様としてDoxygenで明記し呼び出す側に対処をお願いしています。
これは、通常許されることだと思います。

>> OMG RTCの仕様ではどういう接続がnormativeであるかといったことは
>> 詳しくは規定されていませんが、PortProfile.ports に格納されているポートに
>> 対してnotify_connectを次々呼んでConnectorProfileを伝搬させるというふうに書いてあります。
>> 参照：OMG RTC formal/08-04-04 p.75
>> http://www.omg.org/spec/RTC/1.0/
>
> この伝播指せるというのは、私も分かっていましたが、その実装の問題です。
> OpenRTM-aist では、notify_connect の中で、ConnectorProfileにしたがって、
> publishInterfaces を実行したあとに、その他のポートに対して、notify_connectを呼び出して、
> 返事が帰ってくるのを待っています。
> 返事が来ら、そのあとに、subscribeInterfacesを実行するというのが大まかな流れですね。
> この時、CORBAが他のCORBA Objectからの読み出しを直ちに実行することができるという
> 前提になっていますが、CORBAの仕様には、そこまで規定していません。（未規定であるということ）
> そのため、ConnectorProfileによっては、デッドロックを引き起こすこともあります。
> 幸い、現在は、2つのポートの接続なので、それは置きませんが。

すみません、これについてはCORBAの仕様をそこまで深く知らないのでわかりません。
ORBが非スレッドモデルの場合に、同一ORB上のオブジェクトをたがいに呼び出して、
デッドロックに陥るという意味でしょうか？

>> もう少し詳細な仕様については以下のようになっています。
>> http://www.openrtm.org/OpenRTM-aist/documents/current/cxx/classreference_ja/classRTC_1_1PortBase.html#a139d07d2e94f7e793aedf4aa24b92462
>>
> ここに、”connect() および途中の notify_connect() が ConnectorProfile::{name, ports} を変更することはない。”　と書いてありますが、
> notify_connect()をカスケード呼び出しするときには、ConnectorProfile::{name, ports} が変更されて呼び出されます。（IORが追加されます）
> ここが、私がはまったところです。

変更されるのは ConnectorProfile::properties ではないですか？
ConnectorProfileのnameもportもいじらないはずですが、
nameはいじったところであまり得以上はないですが、portは途中で
変更されると、カスケード呼び出しの前提が崩れてしまうので、
絶対に変更してはいけないはずです。
もしいじっている箇所があるとしたらそれはバグになります。
どの部分かお分かりでしたら教えていただけないでしょうか？

ちなみに、notify_connect()のカスケード呼び出しを行う場合、
プロバイダの参照をすべてのportに周知させるために、行きのnotify_connect()で
ConnectorProfile::propertiesにインターフェース名とIOR文字列のペアと、
インターフェース名とAny型に入れたCORBA Objectの2通りで格納しています。
さらに、戻りの呼び出しではコンシューマが自分の取得すべきIORを
ConnectorProfile::propertiesの中から探し出し、プレースホルダに格納します。
一応、こういう流れになっています。

>> InPortからOutPortへの接続とOutPortからInPortへの接続で振る舞いが
>> 違うというのは、SystemEditor側でどういうConnectorProfileをどのポートに
>> 与えるかに依存するので、両社で異なるConnectorProfileを作っていて、
>> かつどちらのポートにそれを渡すかによって違ってきます。
> そうですね。どちらを起点に呼び出しても、OpenRTM側でうまく処理することが前提になっています。
> 接続するときには、どちらが、InPortかOutPortかは、分かっているのですから、
> ConnectorProfileをツールがうまく作ればよいということになりませんか？
> 実際に、RtcHandleでは、同じIDを使わないようにするという対処をしているのですから。

その通りです。なので、ツール側で適切なConnectorProfileを作ってもらえるように、
Doxygenの方でconnect()関数の呼び出し方の決まりをこのように書いています。
で末廣先生のケースでは、connector_idが同じ場合についてDoxygenで、

　ConnectorProfile::connector_id はすべての接続に対して一意な ID (通常はUUID) が格納される。
　UUIDの設定は connect() 関数内で行 われるので、呼び出し側は空文字を設定する。
　既存の接続と同じUUIDを 設定し connect() を呼び出した場合には PRECONDITION_NOT_MET
　エラー を返す。ただし、将来の拡張で既存の接続プロファイルを更新するため に既存の UUID を
　設定して呼び出す使用法が用いられる可能性がある。

こう書かれているように、既存の接続と同じUUIDを設定してconnect()を呼び出してしまったため
問題が起こったのだと思います。（将来を先取りしたとも言えますが、実装が追いついてません。。。）

http://openrtp.jp/openrtm/svn/OpenRTM-aist/branches/RELENG_1_0/OpenRTM-aist/src/lib/rtm/PortBase.cpp

上記のように、実際 connect() に与えられるConnectorProfile::connector_id は空文字が前提ですが、
実装上は、connect()内で

・空文字->UUIDを生成
・既存のID->PRECONDITION_NOT_METエラーを返しログにもその旨出力
・それ以外の文字列->何もしないで通過
　(これはDoxygen上の仕様には明記されておらず、UUIDかどうかのチェックもしていないので
　まずいといえばまずいが、他のConnectorProfileと区別できる一意なキーであればよいので、
　致命的なエラーにはならない。OMG RTCではconnector_idがUUIDとは言ってないし。。。）

というように3つのケースに分けて処理をしています。
ちなみに、ConnectorProfile::connector_id に何もセットしないで呼び出す、
という場合もありますが、この場合CORBAの呼び出し自体がエラーになります。

以上のように、処理の漏れを少なくするようには実装していて、それでも
不十分なところについては、ドキュメント側で制約を設けることにより対処しています。
それでも不十分な個所は沢山あると思いますので、問題点を見つけられた場合は
お知らせいただければ幸いです。＞みなさま

>>> できれば、オフィシャルでダウンロードできるのは、最新で安定している方がよいと思います。
>>> ご検討下さい。
>>
>> 了解しました。パッチなどはできるだけアップするようにしたいと思います。
>
>
> パッチの件は、お願いいたします。
>
> 現在、RtORBでも、一応 OpenRTM-aistが動作していますが、OpenRTM-aistに対して修正をする必要があります。
> OpenRTM-aist-1.0-RELEASEに対して修正したものが、現在アップされていますが、そのパッチの作成もお願い
> できないでしょうか？

検討させていただきます。

-- 
安藤慶昭＠独立行政法人産業技術総合研究所 知能システム研究部門
    統合知能研究グループ 主任研究員, 博士(工学)
    〒305-8568 つくば市梅園1-1-1 中央第2
    e-mail: n-ando ＠ aist.go.jp, web: http://staff.aist.go.jp/n-ando
    OpenRTM-aist: http://www.openrtm.org