清水先生
安藤です
ご提案ありがとうございます。
おっしゃるような初期化順序でも問題なさそうですね。
精査して実装に取り込みたいと思います。
また、init() の引数がconstでない理由はInPortProviderに関する情報を
相手に伝えるためかな、と思ったのですが、以下のドキュメントを読む限り
別途Providerの情報を伝える手段があるのでconstでもいいような気がします。
http://svn.openrtm.org/OpenRTM-aist/tags/RELEASE_1_1_0/OpenRTM-aist/src/lib/rtm/InPortProvider.h
これについても調べて修正します。とりあえずチケット発行しました。
ありがとうございました。
2013年1月4日 17:43 Masayuki Shimizu :
> OpenRTM-aist開発チームの皆さま
>
> 静岡大の清水です。
>
> バッファやコネクタまわりに関しての改善・検討要望です。
> 過日のSI2012で発表した、共有メモリベースの
> データ通信機能を実装する際に問題となった点です。
> ご検討頂ければ幸いです。
>
> 【問題点】
> 現行のコネクタの実装（InPortPushConnectorを例とします）では、
> 以下の手順で初期化（コンストラクタ内で）がされています。
>
> (1) バッファ生成
> (2) プロバイダの初期化（InPortProvider::init()のコール）
>
> 一般に、プロバイダ（コンシューマも）は特定のバッファとの組み合わせでしか
> 動作しない場合も考えられると思います。
> すなわち、プロバイダがどのバッファを生成するかを制御できる必要があります。
>
> どのバッファを生成するかは、ConnectorProfileにbuffer_typeを設定することで
> 制御できますが、もしユーザが間違ったbuffer_typeを指定した場合、
> あるいは何も指定しなかった場合は、プロバイダに適合したバッファが生成されません。
>
> 【対応策】
> この問題は、バッファの生成とプロバイダの初期化の順序を入れ替えることで
> 回避できます。私が実際に変更したコードは以下です。
>
> ・オリジナル（一部のみ抜粋）
> InPortPushConnector(ConnectorInfo info, InPortProvider *provider)
> {
> m_buffer = createBuffer(info);
> m_buffer->init(info.properties.getNode("buffer"));
> m_provider->init(info.properties);
> m_provider->setBuffer(m_buffer);
> m_provider->setListener(info, &m_listeners);
> }
>
> ・変更後
> InPortPushConnector(ConnectorInfo info, InPortProvider *provider)
> {
> m_provider->init(info.properties); //<= バッファ生成前にプロバイダのinit()をする
> m_buffer = createBuffer(info);
> m_buffer->init(info.properties.getNode("buffer"));
> m_provider->setBuffer(m_buffer);
> m_provider->setListener(info, &m_listeners);
> }
>
> 以上のように変更し、自作プロバイダのinit()内でbuffer_typeプロパティを
> 追加（または上書き）すれば、プロバイダがバッファの種類を完全に制御できます。
>
> ところで、プロバイダのinit()の引数がconst指定になっていないのは、
> プロバイダがConnectorProfileの情報（コピー）を書き変えても良いということだと、
> 私は判断しましたが、それで問題ないですよね。
> もし書き換えを許可しないなら、const指定とする必要があります。
>
> 以上、よろしくご検討をお願いいたします。
>
> 清水
> --------------------
> Masayuki Shimizu
> Assistant Professor
> Dept. of Mechanical Engineering, Shizuoka Univ.
> 3-5-1, Johoku, Naka-ku, Hamamatsu 432-8561, JAPAN
> TEL/FAX: +81-53-478-1061
> Email: tmsimiz@ipc.shizuoka.ac.jp
> _______________________________________________
> openrtm-users mailing list
> openrtm-users@openrtm.org
> http://www.openrtm.org/mailman/listinfo/openrtm-users
_______________________________________________
openrtm-users mailing list
openrtm-users@openrtm.org
http://www.openrtm.org/mailman/listinfo/openrtm-users
OpenRTM-aist開発チームの皆さま
静岡大の清水です。
バッファやコネクタまわりに関しての改善・検討要望です。
過日のSI2012で発表した、共有メモリベースの
データ通信機能を実装する際に問題となった点です。
ご検討頂ければ幸いです。
【問題点】
現行のコネクタの実装（InPortPushConnectorを例とします）では、
以下の手順で初期化（コンストラクタ内で）がされています。
(1) バッファ生成
(2) プロバイダの初期化（InPortProvider::init()のコール）
一般に、プロバイダ（コンシューマも）は特定のバッファとの組み合わせでしか
動作しない場合も考えられると思います。
すなわち、プロバイダがどのバッファを生成するかを制御できる必要があります。
どのバッファを生成するかは、ConnectorProfileにbuffer_typeを設定することで
制御できますが、もしユーザが間違ったbuffer_typeを指定した場合、
あるいは何も指定しなかった場合は、プロバイダに適合したバッファが生成されません。
【対応策】
この問題は、バッファの生成とプロバイダの初期化の順序を入れ替えることで
回避できます。私が実際に変更したコードは以下です。
・オリジナル（一部のみ抜粋）
InPortPushConnector(ConnectorInfo info, InPortProvider *provider)
{
m_buffer = createBuffer(info);
m_buffer->init(info.properties.getNode("buffer"));
m_provider->init(info.properties);
m_provider->setBuffer(m_buffer);
m_provider->setListener(info, &m_listeners);
}
・変更後
InPortPushConnector(ConnectorInfo info, InPortProvider *provider)
{
m_provider->init(info.properties); //<= バッファ生成前にプロバイダのinit()をする
m_buffer = createBuffer(info);
m_buffer->init(info.properties.getNode("buffer"));
m_provider->setBuffer(m_buffer);
m_provider->setListener(info, &m_listeners);
}
以上のように変更し、自作プロバイダのinit()内でbuffer_typeプロパティを
追加（または上書き）すれば、プロバイダがバッファの種類を完全に制御できます。
ところで、プロバイダのinit()の引数がconst指定になっていないのは、
プロバイダがConnectorProfileの情報（コピー）を書き変えても良いということだと、
私は判断しましたが、それで問題ないですよね。
もし書き換えを許可しないなら、const指定とする必要があります。
以上、よろしくご検討をお願いいたします。
清水
--------------------
Masayuki Shimizu
Assistant Professor
Dept. of Mechanical Engineering, Shizuoka Univ.
3-5-1, Johoku, Naka-ku, Hamamatsu 432-8561, JAPAN
TEL/FAX: +81-53-478-1061
Email: tmsimiz@ipc.shizuoka.ac.jp
_______________________________________________
openrtm-users mailing list
openrtm-users@openrtm.org
http://www.openrtm.org/mailman/listinfo/openrtm-users