末廣先生
安藤です
> 皆様，
>
> 末廣＠電通大です．
> rtc_handle for OpenRTM-aist-1.0.0が安定してきたのでご報告します．
>
> これまでポートの接続，切断，再接続などの処理が安定しなかった問題を解決しました．
> に置いてあります．
> 0.4.2版からの注意点も簡単に記述してありますので参考にしてください．
>
> もしご興味があれば使ってみて下さい．
アナウンスありがとうございます。
参考のために、接続が安定しなかった原因と、どのような変更によって
安定するようになったのかを教えていただけないでしょうか？
よろしくお願いいたします。
安藤様，
末廣です．
今，個人PCが故障中でgmailから出しているので私のメールは
メーリングリストには流れていないと思います．
前のメールは安藤さんのreplyのおかげで流れたことになるのかな．
ありがとうございます．
で，原因ですが，
0.4xではconnectorは仮想的なもので，ある意味実体がなかったのですが
Connector が1.0.0では実体を持つようになったためdisconnectすると
それが開放されてしまうことが分かりました．いったんdisconnectした
connector_idを再利用すると接続ができないことがあります．
またうまくいっているようでも，古いconnector_idを使って何度も
接続，切断を繰り返しているとコンポーネント本体が死ぬこともあるようです．
そういうゴミ接続ができると，他のツール（rtcshellなど）を使って
接続，切断を繰り返していてもコンポーネントが死にます．
そこで対策としてconnectするときに常に新しいConnectorを生成し、
情報を更新するようにしました。
今のところうまくいっているように見えます．
2010年11月10日2:46 Ando Noriaki :
> 末廣先生
>
> 安藤です
>
>> 皆様，
>>
>> 末廣＠電通大です．
>> rtc_handle for OpenRTM-aist-1.0.0が安定してきたのでご報告します．
>>
>> これまでポートの接続，切断，再接続などの処理が安定しなかった問題を解決しました．
>> に置いてあります．
>> 0.4.2版からの注意点も簡単に記述してありますので参考にしてください．
>>
>> もしご興味があれば使ってみて下さい．
>
> アナウンスありがとうございます。
> 参考のために、接続が安定しなかった原因と、どのような変更によって
> 安定するようになったのかを教えていただけないでしょうか？
> よろしくお願いいたします。
>
安藤さん、末廣さん：
原＠産総研です。下記のような実装では、メモリーリークにつながっているということはないでしょうか？
数回、接続、切断を繰り返しているとコンポーネントが死ぬということは、どこかで余計なメモリ開放
が行われているのではないでしょうか？
だとすると、残っているメモリもあると思われます。
もう一度、ソースコードを見直して、シンプルにできないでしょうか。
私は、現在、RtORBでいろいろ試しているのですが、データポートのIn->Outで接続を行うときと
Out->Inで接続を行うときの振舞が違います。サービスポートでも同じように、接続の振舞が違うようです。
RTCの生成、ポートの接続に関して、動のような動作が正常であるのかが分かる文書があればよいのですが、、、
それから、MLで流れた修正などが、オフィシャルのホームページに見当たりませんが、パッチと修正点を
載せて頂けないでしょうか？
できれば、オフィシャルでダウンロードできるのは、最新で安定している方がよいと思います。
ご検討下さい。
On 2010/11/10, at 6:46, takashi suehiro wrote:
> 安藤様，
>
> 末廣です．
> 今，個人PCが故障中でgmailから出しているので私のメールは
> メーリングリストには流れていないと思います．
> 前のメールは安藤さんのreplyのおかげで流れたことになるのかな．
> ありがとうございます．
>
> で，原因ですが，
> 0.4xではconnectorは仮想的なもので，ある意味実体がなかったのですが
> Connector が1.0.0では実体を持つようになったためdisconnectすると
> それが開放されてしまうことが分かりました．いったんdisconnectした
> connector_idを再利用すると接続ができないことがあります．
> またうまくいっているようでも，古いconnector_idを使って何度も
> 接続，切断を繰り返しているとコンポーネント本体が死ぬこともあるようです．
> そういうゴミ接続ができると，他のツール（rtcshellなど）を使って
> 接続，切断を繰り返していてもコンポーネントが死にます．
>
> そこで対策としてconnectするときに常に新しいConnectorを生成し、
> 情報を更新するようにしました。
> 今のところうまくいっているように見えます．
>
> 2010年11月10日2:46 Ando Noriaki :
>> 末廣先生
>>
>> 安藤です
>>
>>> 皆様，
>>>
>>> 末廣＠電通大です．
>>> rtc_handle for OpenRTM-aist-1.0.0が安定してきたのでご報告します．
>>>
>>> これまでポートの接続，切断，再接続などの処理が安定しなかった問題を解決しました．
>>> に置いてあります．
>>> 0.4.2版からの注意点も簡単に記述してありますので参考にしてください．
>>>
>>> もしご興味があれば使ってみて下さい．
>>
>> アナウンスありがとうございます。
>> 参考のために、接続が安定しなかった原因と、どのような変更によって
>> 安定するようになったのかを教えていただけないでしょうか？
>> よろしくお願いいたします。
>>
原様
安藤です
> 安藤さん、末廣さん：
>
> 原＠産総研です。下記のような実装では、メモリーリークにつながっているということはないでしょうか？
> 数回、接続、切断を繰り返しているとコンポーネントが死ぬということは、どこかで余計なメモリ開放
> が行われているのではないでしょうか？
> だとすると、残っているメモリもあると思われます。
1.0をリリースするときに行ったメモリリークテストでは、データポート
サービスポートともにメモリリークは発見されていませんので、
（仕様に従って呼び出している限りは）たぶん大丈夫だと思います。
ちなみに、メモリリークテストでは、rtc_handleをこちらで1.0用にアップデート
したものを使用しておりました。接続プロファイルの作成の仕方は
以下の仕様に従って行っておりました。
> もう一度、ソースコードを見直して、シンプルにできないでしょうか。
PortBaseは特別複雑なコードになっているようには見えないのですが、
具体的にどの辺が複雑なのかご指摘いただければ検討したいと思います。
PortBaseクラスの見かたとしては、protectedのメンバー関数の多くが
template methodパターンのメソッドとなっているものとして見ていくと
振る舞いをとらえやすいと思います。
> 私は、現在、RtORBでいろいろ試しているのですが、データポートのIn->Outで接続を行うときと
> Out->Inで接続を行うときの振舞が違います。サービスポートでも同じように、接続の振舞が違うようです。
>
> RTCの生成、ポートの接続に関して、動のような動作が正常であるのかが分かる文書があればよいのですが、、、
OMG RTCの仕様ではどういう接続がnormativeであるかといったことは
詳しくは規定されていませんが、PortProfile.ports に格納されているポートに
対してnotify_connectを次々呼んでConnectorProfileを伝搬させるというふうに書いてあります。
参照：OMG RTC formal/08-04-04 p.75
http://www.omg.org/spec/RTC/1.0/
例としてport参照の配列に格納された順にnotify_connect()をカスケード上に
呼び出すというシーケンス図が示されています。ちなみに、OpenRTMでは
この図の通りの実装になっています。
もう少し詳細な仕様については以下のようになっています。
http://www.openrtm.org/OpenRTM-aist/documents/current/cxx/classreference_ja/classRTC_1_1PortBase.html#a139d07d2e94f7e793aedf4aa24b92462
データポートもサービスポートもこの実装に従って実装されているはず？です。
InPortからOutPortへの接続とOutPortからInPortへの接続で振る舞いが
違うというのは、SystemEditor側でどういうConnectorProfileをどのポートに
与えるかに依存するので、両社で異なるConnectorProfileを作っていて、
かつどちらのポートにそれを渡すかによって違ってきます。
OpenRTMのポート自体は、仕様を満たすConnectorProfileを与えられたら
その通りに動作するだけです。
> それから、MLで流れた修正などが、オフィシャルのホームページに見当たりませんが、パッチと修正点を
> 載せて頂けないでしょうか？
>
> できれば、オフィシャルでダウンロードできるのは、最新で安定している方がよいと思います。
> ご検討下さい。
了解しました。パッチなどはできるだけアップするようにしたいと思います。
以上、よろしくお願いいたします。
> On 2010/11/10, at 6:46, takashi suehiro wrote:
>
>> 安藤様，
>>
>> 末廣です．
>> 今，個人PCが故障中でgmailから出しているので私のメールは
>> メーリングリストには流れていないと思います．
>> 前のメールは安藤さんのreplyのおかげで流れたことになるのかな．
>> ありがとうございます．
>>
>> で，原因ですが，
>> 0.4xではconnectorは仮想的なもので，ある意味実体がなかったのですが
>> Connector が1.0.0では実体を持つようになったためdisconnectすると
>> それが開放されてしまうことが分かりました．いったんdisconnectした
>> connector_idを再利用すると接続ができないことがあります．
>> またうまくいっているようでも，古いconnector_idを使って何度も
>> 接続，切断を繰り返しているとコンポーネント本体が死ぬこともあるようです．
>> そういうゴミ接続ができると，他のツール（rtcshellなど）を使って
>> 接続，切断を繰り返していてもコンポーネントが死にます．
>>
>> そこで対策としてconnectするときに常に新しいConnectorを生成し、
>> 情報を更新するようにしました。
>> 今のところうまくいっているように見えます．
>>
>> 2010年11月10日2:46 Ando Noriaki :
>>> 末廣先生
>>>
>>> 安藤です
>>>
>>>> 皆様，
>>>>
>>>> 末廣＠電通大です．
>>>> rtc_handle for OpenRTM-aist-1.0.0が安定してきたのでご報告します．
>>>>
>>>> これまでポートの接続，切断，再接続などの処理が安定しなかった問題を解決しました．
>>>> に置いてあります．
>>>> 0.4.2版からの注意点も簡単に記述してありますので参考にしてください．
>>>>
>>>> もしご興味があれば使ってみて下さい．
>>>
>>> アナウンスありがとうございます。
>>> 参考のために、接続が安定しなかった原因と、どのような変更によって
>>> 安定するようになったのかを教えていただけないでしょうか？
>>> よろしくお願いいたします。
>>>
>>
>
>
安藤様，
末廣です．
(10/11/11 1:27), Ando Noriaki wrote:
> ちなみに、メモリリークテストでは、rtc_handleをこちらで1.0用にアップデート
> したものを使用しておりました。接続プロファイルの作成の仕方は
> 以下の仕様に従って行っておりました。
この rtc_handle は公開されないのでしょうか？
接続プロファイルの作成や接続後のポート情報の取り出しなどには
結構試行錯誤しているので開発元からの情報があると確実なのですが．
複数のバージョンがあると混乱するのでどこかでマージした方が良いのかな．
私のものは松坂さんがRC版対応にしてくれたものを含んでいます．
よろしくお願いします．
末廣先生
安藤です
こちらで修正した rtc_handle.py はここにあります。
http://openrtp.jp/openrtm/svn/OpenRTM-aist/branches/RELENG_1_0/OpenRTM-aist/examples/AutoTest/
connectの呼び出しについては参考にはなるかもしれませんが、
このAutoTestコンポーネント用に修正しただけだったと思います。
ちなみに、このAutoTestコンポーネントとrtc_handle.pyを利用して、
http://openrtp.jp/openrtm/svn/OpenRTM-aist/branches/RELENG_1_0/OpenRTM-aist/examples/tests/ConnectRTCTest.py
ではconnectとdisconnectの繰り返しで実際にメモリ使用量が増えているかどうかを
チェックしていたと思います。
2010年11月11日7:14 ts :
> 安藤様，
>
> 末廣です．
>
> (10/11/11 1:27), Ando Noriaki wrote:
>
>> ちなみに、メモリリークテストでは、rtc_handleをこちらで1.0用にアップデート
>> したものを使用しておりました。接続プロファイルの作成の仕方は
>> 以下の仕様に従って行っておりました。
>
> この rtc_handle は公開されないのでしょうか？
> 接続プロファイルの作成や接続後のポート情報の取り出しなどには
> 結構試行錯誤しているので開発元からの情報があると確実なのですが．
>
> 複数のバージョンがあると混乱するのでどこかでマージした方が良いのかな．
> 私のものは松坂さんがRC版対応にしてくれたものを含んでいます．
>
> よろしくお願いします．
>
安藤様，
末廣です．
ありがとうございます．
ただ，おっしゃるように旧版とほとんど同じですね．
これで何故うまくいっているのかと思ったら，
AutoTestの方を見て納得しました．
rtc_handleのConnectorを使わずに，
RTC.ConnectorProfileを直接生成して
portにconnectさせていたのですね．
...とここまで書いたのですが，やはり納得できません．
結局，CnnectorProfileにconnector_idが書き込まれて戻ってくるので
ループの2回目以降はconnector_idを指定した状態で
connectすることになると思うのですが,,,.
idに"123"などの文字列を指定しているからOKなのだろうか？
・既存のID->PRECONDITION_NOT_METエラーを返しログにもその旨出力
これはどういう意味でしょうか？
切断されると「既存のID」ではなくなる？
だとすると接続が不安定だった原因の解釈が変わってきます．
「ID指定」and「そのIDのprofileの解放」で失敗していたと思ったのですが，
本当は「ID指定」and「そのIDのprofileの残骸」で失敗していたということに
なるような気がします．
実のところどうなのでしょう．
安全に使うにはもう少し調べてみる必要がありそうです．
(10/11/11 7:42), Ando Noriaki wrote:
> 末廣先生
>
> 安藤です
>
> こちらで修正した rtc_handle.py はここにあります。
> http://openrtp.jp/openrtm/svn/OpenRTM-aist/branches/RELENG_1_0/OpenRTM-aist/examples/AutoTest/
> connectの呼び出しについては参考にはなるかもしれませんが、
> このAutoTestコンポーネント用に修正しただけだったと思います。
>
> ちなみに、このAutoTestコンポーネントとrtc_handle.pyを利用して、
> http://openrtp.jp/openrtm/svn/OpenRTM-aist/branches/RELENG_1_0/OpenRTM-aist/examples/tests/ConnectRTCTest.py
> ではconnectとdisconnectの繰り返しで実際にメモリ使用量が増えているかどうかを
> チェックしていたと思います。
>
>
> 2010年11月11日7:14 ts :
>> 安藤様，
>>
>> 末廣です．
>>
>> (10/11/11 1:27), Ando Noriaki wrote:
>>
>>> ちなみに、メモリリークテストでは、rtc_handleをこちらで1.0用にアップデート
>>> したものを使用しておりました。接続プロファイルの作成の仕方は
>>> 以下の仕様に従って行っておりました。
>>
>> この rtc_handle は公開されないのでしょうか？
>> 接続プロファイルの作成や接続後のポート情報の取り出しなどには
>> 結構試行錯誤しているので開発元からの情報があると確実なのですが．
>>
>> 複数のバージョンがあると混乱するのでどこかでマージした方が良いのかな．
>> 私のものは松坂さんがRC版対応にしてくれたものを含んでいます．
>>
>> よろしくお願いします．
末廣先生
松坂です。
2010/11/11 ts :
> 複数のバージョンがあると混乱するのでどこかでマージした方が良いのかな．
> 私のものは松坂さんがRC版対応にしてくれたものを含んでいます．
Geoffreyさんのコードのパッチを作るためにgithubを使い始めたのですが、なかなか便利です。
特にrtc_handleは、各所で自己流拡張が施されている人気ツールだと思うので、自己流拡張を許しつつ
役に立ちそうな部分をメインのソースにマージしていくような用途にはgithubが最適だと思います。
皆様，
末廣＠電通大です．
私のところでもHiroNXを使い始めました．
そのときTimedJointDataの取り扱いでトラブルがあったので
rtc_handleを改訂しました．改訂版は，
に
置いてあります．概要は，
・2013/02/25: RTC.TimedJointData などのデータ生成に引数が
２つではないデータ型に対するPipeの生成ができるようになりました。
*rtc_handle_20130225.pyを持っていってrtc_handle.pyにrenameして
使って下さい。
*omniORBpyの内部のデータ型情報を使ってdeepにダミーデータを
生成しています。
*属性名やリストなどの構造は再現されます。最後の基本データ部には
ダミーでデータコードが入ります。
*今のところは、まだ、RTC.xxxxのデータ型にしか対応していません。
ユーザ定義データ型への一般対応は今後の課題です。
ということになります．
以下，少し解説です．
deep_dummy_dataに，omniORBpyの内部の型データ，
たとえばRTC._d_TimedDoubleSeqを引数にあたえると
ダミーデータが出来ます．
（RTC._tc_TimedDoubleSeq._dも同じもの)
たとえば，内部の型データは以下のようになっています．
>>> RTC._d_TimedDoubleSeq
(15, ,
'IDL:RTC/TimedDoubleSeq:1.0', 'TimedDoubleSeq', 'tm',
(15, , 'IDL:RTC/Time:1.0',
'Time', 'sec', 5, 'nsec', 5), 'data', (19, 7, 0))
これでダミーデータを作るのは以下のようにします．
>>> deep_dummy_data(RTC._d_TimedDoubleSeq)
RTC.TimedDoubleSeq(tm=RTC.Time(sec=5, nsec=5), data=[7])
ここで，5や7の数字が基本データ型を表しています（たぶん）．
5がlong, 7がdoubleなどを意味しています．
shallow_dummy_data（与える引数は，tcそのもの)でも問題ない
とおもうのですが(*)，少し凝ってみました．
実は，まだ解釈できないデータ型もあるので(14とか),
必要があれば教えて下さい．
* いずれにしても読むときは相手が正しいデータを送ってくるし，
書くときはどこかで正しいデータを作る必要があります．
安藤さん：
原です。
connect()関数ですが、私もソースコードを追って見ました。RtORBの接続不良の原因は、RtORB側にありましたが、
実装上少し問題も残っています。
On 2010/11/11, at 1:27, Ando Noriaki wrote:
>>
>> だとすると、残っているメモリもあると思われます。
>
> 1.0をリリースするときに行ったメモリリークテストでは、データポート
> サービスポートともにメモリリークは発見されていませんので、
> （仕様に従って呼び出している限りは）たぶん大丈夫だと思います。
この仕様に従っているというのが曲者です。仕様にしたがっているからと言ってメモリーリークがないわけでは
ありません。その実装によると思います。
> 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つのポートの接続なので、それは置きませんが。
> もう少し詳細な仕様については以下のようになっています。
> 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が追加されます）
ここが、私がはまったところです。
> InPortからOutPortへの接続とOutPortからInPortへの接続で振る舞いが
> 違うというのは、SystemEditor側でどういうConnectorProfileをどのポートに
> 与えるかに依存するので、両社で異なるConnectorProfileを作っていて、
> かつどちらのポートにそれを渡すかによって違ってきます。
そうですね。どちらを起点に呼び出しても、OpenRTM側でうまく処理することが前提になっています。
接続するときには、どちらが、InPortかOutPortかは、分かっているのですから、ConnectorProfileをツールがうまく作ればよい
ということになりませんか？
実際に、RtcHandleでは、同じIDを使わないようにするという対処をしているのですから。
>>
>> できれば、オフィシャルでダウンロードできるのは、最新で安定している方がよいと思います。
>> ご検討下さい。
>
> 了解しました。パッチなどはできるだけアップするようにしたいと思います。
パッチの件は、お願いいたします。
現在、RtORBでも、一応 OpenRTM-aistが動作していますが、OpenRTM-aistに対して修正をする必要があります。
OpenRTM-aist-1.0-RELEASEに対して修正したものが、現在アップされていますが、そのパッチの作成もお願い
できないでしょうか？
安藤です
>> 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に対して修正したものが、現在アップされていますが、そのパッチの作成もお願い
> できないでしょうか？
検討させていただきます。
安藤さん：
原＠産総研です。そちらは、もう深夜では？
On 2010/11/11, at 9:20, Ando Noriaki wrote:
>
> 上の文章の意味は、下のDosygenのドキュメント上の（OMG RTCの方でなく、私が決めた）仕様に従って
> connect()を呼び出している限りは、その仕様に従ってメモリリークテストをしており、
> リークは検出されなかった、という事実を述べただけです。
了解しました。
>
> Dosygenで書かれた仕様で想定されている以外の方法で（例えば変なConnectorProfileを
> connect()に与えるなど）呼び出された場合は、リークするかもしれませんし、
> 最悪クラッシュするかもしれません。引数に与えられたConnectorProfileに不整合が
> あった場合、極力検出してエラーにするなど対処はしているつもりですが、
> それにも限界はあるので、仕様としてDoxygenで明記し呼び出す側に対処をお願いしています。
> これは、通常許されることだと思います。
それはそうなのですが、通常許されても、安全なコードを書くためのガイドラインが必要では？
OpenRTM-aistを使っていれば、安全なコンポーネントができるとうことをいうためには、
ガイドラインが必須だと思います。
>
> すみません、これについてはCORBAの仕様をそこまで深く知らないのでわかりません。
> ORBが非スレッドモデルの場合に、同一ORB上のオブジェクトをたがいに呼び出して、
> デッドロックに陥るという意味でしょうか？
>
その通りです。disconnect()では、しっかりデッドロックが起こっていました。
>>> もう少し詳細な仕様については以下のようになっています。
>>> 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は途中で
> 変更されると、カスケード呼び出しの前提が崩れてしまうので、
> 絶対に変更してはいけないはずです。
私が見たところ、nameとportは変更されていませんでした。
> もしいじっている箇所があるとしたらそれはバグになります。
> どの部分かお分かりでしたら教えていただけないでしょうか？
>
> ちなみに、notify_connect()のカスケード呼び出しを行う場合、
> プロバイダの参照をすべてのportに周知させるために、行きのnotify_connect()で
> ConnectorProfile::propertiesにインターフェース名とIOR文字列のペアと、
> インターフェース名とAny型に入れたCORBA Objectの2通りで格納しています。
> さらに、戻りの呼び出しではコンシューマが自分の取得すべきIORを
> ConnectorProfile::propertiesの中から探し出し、プレースホルダに格納します。
> 一応、こういう流れになっています。
これは、ソースコードを追っていてわかりました。ところで、インターフェース名とIORの文字列は、
同じものですので、どちらか必要ないのでは？
>
> その通りです。なので、ツール側で適切なConnectorProfileを作ってもらえるように、
> Doxygenの方でconnect()関数の呼び出し方の決まりをこのように書いています。
そうであれば、SystemEditorは、実装を変更して欲しいものです。ConnectorProfileの起点が
最初にポイントしたコンポーネントになっています。
> で末廣先生のケースでは、connector_idが同じ場合についてDoxygenで、
>
> ConnectorProfile::connector_id はすべての接続に対して一意な ID (通常はUUID) が格納される。
> UUIDの設定は connect() 関数内で行 われるので、呼び出し側は空文字を設定する。
> 既存の接続と同じUUIDを 設定し connect() を呼び出した場合には PRECONDITION_NOT_MET
> エラー を返す。ただし、将来の拡張で既存の接続プロファイルを更新するため に既存の UUID を
> 設定して呼び出す使用法が用いられる可能性がある。
>
> こう書かれているように、既存の接続と同じUUIDを設定してconnect()を呼び出してしまったため
> 問題が起こったのだと思います。（将来を先取りしたとも言えますが、実装が追いついてません。。。）
なるほど、UUIDを使っていたのですね。name-UUIDのマップがあれば、nameで指定すればよいと思いますが。
>
> 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の呼び出し自体がエラーになります。
>
> 以上のように、処理の漏れを少なくするようには実装していて、それでも
> 不十分なところについては、ドキュメント側で制約を設けることにより対処しています。
> それでも不十分な個所は沢山あると思いますので、問題点を見つけられた場合は
> お知らせいただければ幸いです。＞みなさま
これも、ソースコードを読んでいくうちに分かっていましたが、OpenRTMの移植に必要な情報、RTCを作成
するときの注意点などが、Doxygenの文章で散在しているので、ここを読めばという、まとまった文書がないと
なかなか難しいと思います。
検索すればと言われてもキーがわかりませんし、Doxygenの文書のところにキーワードがあると思いますが、
どのようなキーワードかがREADMEなどのトップ文書で明示的に書いていないでわかりにくい原因になって
いると思います。
文書作成は、使う側の視点での作成が重要です。私の個人的な印象ですが、文書が十分あるが、まとまっていないので
探しにくいです。
| 2.0.0-RELESE | Download page |
| RT-Component | 153.5 |
| RT-Middleware | 35 |
| Tools | 22 |
| Documentation | 2 |
Motion editor/Dynamics simulator
Dynamics simulator
Integrated Development Platform
RT-Components collection by AIST
Tokyo Opensource Robotics Association
Middleware for DAQ (Data Aquisition) by KEK
皆様，
末廣＠電通大です．
rtc_handle for OpenRTM-aist-1.0.0が安定してきたのでご報告します．
これまでポートの接続，切断，再接続などの処理が安定しなかった問題を解決しました．
に置いてあります．
0.4.2版からの注意点も簡単に記述してありますので参考にしてください．
もしご興味があれば使ってみて下さい．