コア: チケット
https://www.openrtm.org/redmine/
https://www.openrtm.org/redmine/redmine/favicon.ico
2017-12-10T22:39:43Z
Redmine for OpenRTM-aist
Redmine
バグ #4391 (終了): 文字化け修正
https://www.openrtm.org/redmine/issues/4391
2017-12-10T22:39:43Z
n-ando
Noriaki.Ando@gmail.com
マージに伴い、コメントの日本語が化けたので修正。<br />trunk/OpenRTM-aist/src/lib/rtm の以下のファイルを修正。
<ul>
<li>InPortDirectConsumer.cpp</li>
<li>InPortCorbaCdrConsumer.cpp</li>
<li>ConnectorListener.h</li>
</ul>
バグ #4145 (終了): ConnectorProfileへのrtc.confからのプロパティの反映
https://www.openrtm.org/redmine/issues/4145
2017-07-19T00:15:24Z
n-ando
Noriaki.Ando@gmail.com
<p>rtc.confから与えられるバッファ長、ポリシーなどのプロパティが実際には設定されているものの、ConnectorProfileには反映されていない。<br />ConnectorProfile.properties -> coil::Properties の操作は行われているものの、逆に書き戻す操作が行われていないため。<br />これを実装して、RTSEなどからも設定された値が見えるようにする。</p>
バグ #3940 (新規): CorbaNaming.cppのポインタ演算
https://www.openrtm.org/redmine/issues/3940
2017-02-10T02:48:12Z
n-ando
Noriaki.Ando@gmail.com
<pre>
void CorbaNaming::nameToString(const CosNaming::Name& name,
char* string_name,
CORBA::ULong slen)
{
char* s = string_name;
for (CORBA::ULong i = 0; i < name.length(); ++i)
{
// Copy id to string_name
for (const char* id = name[i].id; *id != '\0'; ++id) // ここがMISRAで Pointer arithmetic is not on array. の指摘が出る
</pre>
<p>以下の指摘の対処を行う。</p>
<ul>
<li>CorbaNaming.cpp 927 Pointer arithmetic is not on array.</li>
<li>CorbaNaming.cpp 937 Pointer arithmetic is not on array.</li>
<li>CorbaNaming.cpp 963 Pointer arithmetic is not on array.</li>
<li>CorbaNaming.cpp 976 Pointer arithmetic is not on array.</li>
</ul>
バグ #3697 (担当): ECにアタッチされたRTCが即座に追加されないためACTIVATE時に適切に遷移しない問題
https://www.openrtm.org/redmine/issues/3697
2016-10-31T07:06:41Z
n-ando
Noriaki.Ando@gmail.com
<pre>
金広です。
ありがとうございます。
動くようになってきました。
ただまだ問題があります。
rtc1,rtc2,rtc3と3つのコンポーネントを作って、rtc1の実行コンテキストを使って
rtc2,rtc3も直列実行するように設定すると、
https://github.com/fkanehiro/hrpsys-base/blob/master/python/rtm.py#L454
rtc1,rtc2,rtc3という順序でactivateすれば問題ないのですが、rtc3,rtc2,rtc1と
いう順序でactivateすると、rtc3とrtc2はACTIVE_STATEに遷移しません。
この辺りも何か作法に変更あったのでしょうか。
</pre>
<pre>
ロボットソフトウェアプラットフォーム研究チームの宮本と申します。
実行コンテキストで複数のコンポーネントを実行する際にactivateする順序によって一部のコンポーネントがACTIVE_STATEに遷移しない問題ですが、原因を特定できたのでご報告いたします。
まず実行コンテキストにアタッチしたコンポーネントはExecutionContextWorkerクラスのm_compsという配列に追加されるのですが、ExecutionContextインターフェースのadd_componentで実行コンテキストにコンポーネントを追加しようとても即座にはm_compsにコンポーネントは追加されません。
この時点では別の配列に格納しておいて、updateComponentListという関数が呼び出された時点でm_compsに追加されます。
コンポーネントの処理実行中にコンポーネントの追加をしないようにするために、このようになっています。
> rtc1,rtc2,rtc3という順序でactivateすれば問題ないのですが、rtc3,rtc2,rtc1と
> いう順序でactivateすると、rtc3とrtc2はACTIVE_STATEに遷移しません。
updateComponentList関数はinvokeWorkerDoという関数で呼び出されていて、invokeWorkerDo関数はPeriodicExecutionContextのsvc関数で呼び出されています。
ただ全てのコンポーネントがINACTIVE_STATEの場合、以下の箇所で処理が止められてしまいinvokeWorkerDo関数が実行されずupdateComponentList関数も実行されません。
int PeriodicExecutionContext::svc(void)
{
(省略)
Guard guard(m_workerthread.mutex_);
while (!m_workerthread.running_)
{
m_workerthread.cond_.wait();
//ここで止められているため下のinvokeWorkerDo関数は実行されず、updateComponentList関数も実行されない
//既にアタッチしたコンポーネントをアクティブにするとsignal関数が呼び出されて下の処理が実行される
}
}
coil::TimeValue t0(coil::gettimeofday());
ExecutionContextBase::invokeWorkerDo();
ExecutionContextBase::invokeWorkerPostDo();
coil::TimeValue t1(coil::gettimeofday());
既にアタッチしてあるコンポーネントをactivateした場合、invokeWorkerDo関数が呼び出されてupdateComponentList関数も呼び出されるのでコンポーネントが追加されます。
rtc1をrtc2、rtc3より先にactivateした場合にはm_compsにrtc2、rtc3が追加されているのでACTIVE_STATEに遷移しますが、rtc2、rtc3を先にactivateした場合はこの時点でm_compsにrtc2、rtc3が追加されておらずコンポーネントを見つけられずに失敗します。
全てのコンポーネントがINACTIVE_STATEの時にコンポーネントを追加しても問題はないので、今後修正する予定です。
よろしくお願いします。
</pre>
バグ #3574 (終了): Manager::getORB() 等のリファレンスカウントとownershipを整理する
https://www.openrtm.org/redmine/issues/3574
2016-07-19T04:35:59Z
n-ando
Noriaki.Ando@gmail.com
<p>getORB(),getPOA(),getPOAManager() などはリファレンスカウントを増やさずに参照を返すため_varで受けるとオブジェクトが削除される問題。<br />CORBAのマナー的には、関数内でduplicateなどでリファレンスカウントを増やしownershipを保持したまま、参照を返すべき。</p>
<pre>
安藤様
宮本です。
direct接続したときに発生する不具合ですが、原因を特定できたのでご報告します。
まず原因箇所はOutPortBaseクラスのgetLocalInPort関数の以下の部分でした。
CORBA::ORB_var orb = RTC::Manager::instance().getORB();
PortableServer::POA_var poa = RTC::Manager::instance().getPOA();
この部分を以下のように修正したら不具合は発生しなくなりました。
CORBA::ORB_var orb = CORBA::ORB::_duplicate(RTC::Manager::instance().getORB());
PortableServer::POA_var poa = PortableServer::POA::_duplicate(RTC::Manager::instance().getPOA());
修正前のようにgetORB関数で取得したポインタをそのまま渡してしまうと、ORB_varのデストラクタでCORBA::release関数を呼び出してリファレンスカウントが1つ減ります。
つまりgetLocalInPort関数を呼び出すたびにリファレンスカウントが減ってしまうのが原因なので、_duplicate関数でリファレンスカウントを増やしてやれば不具合はなくなるはずです。
ソースコードを読んだ結果、以下の部分にも同様の記述があったので修正する必要があると思います。
・CORBA_SeqUtil.cppのrefToVstring関数
・CorbaNamingクラスのコンストラクタ
以上です。
</pre>
バグ #3509 (新規): Peiorid と New のパフォーマンスとロックの調査と見直し
https://www.openrtm.org/redmine/issues/3509
2016-04-11T04:35:32Z
n-ando
Noriaki.Ando@gmail.com
<p><a class="external" href="https://github.com/fkanehiro/hrpsys-base/issues/552#issuecomment-207982877">https://github.com/fkanehiro/hrpsys-base/issues/552#issuecomment-207982877</a></p>
<p>理論的には Newの方がPeriodicよりパフォーマンスは良いはずだが、そうはなっていないようなので、スレッド、ロック回りを再度見直す。</p>
<pre>
ありがとうございます。
(1) 両方とも非リアルタイムスレッドです。それ故、periodicの周期の正確さは保証されません。
(2) newだと、onExecute() がバッファに書き込み後、signalでpublisherスレッドを起こすので、publish作業(正確には、publisherスレッドがバッファからデータを取り出す時間)が 4ms-2ms (250Hz-500Hz) 以内に終われば、次のonExecute()の書き込みを妨げない。ゆえに、ロックを取り合うことはほとんどない。
periodic の場合は、仮に onExecute()が500Hzで、publisherが50Hzとすると、publisherが1回送信して待っている間に、onExecute()は10回書き込み、デフォルトバッファ長8のままだとを超えるので、すぐにバッファフル状態になります。(バッファ長が有限長ならいずれフル状態になる。)
ロックを取り合う確率がperiodicが高いのは、publisherの実行タイミングとonExecute(のwrite部分)の実行タイミングに関して、
newであれば、onExecuteのwriteのタイミングでpublisherが呼ばれるので、ほぼpublisherとonExecuteは同期がとれてることになる。そのため、概ね猶予は4msくらいはあるので、送信がこれまでに終わって入れば大丈夫
periodicであれば、publiserの呼ばれるタイミングはonExecuteとは同期がとれてないことになる(publisherが非実時間スレッドなため)。そのため、送信時間がたとえ短くても、onExecuteのタイミングと周期実行時のpublisherの実行タイミングが近いと、ロックを取り合う確率が高くなる。
ということでしょうか。
少し前にこちらで試してみた現象としては、実時間制御周期250[hz]で 実時間制御RTC<=>外部のRTC の通信を行ったときに、
subscription_typeがnewで、実時間制御RTCが4msでまわらず、実時間をまもれてない
subscription_typeがperiodicで、push_rateを50[hz]とすると実時間制御RTCが4[ms]を守れている
のようでした。
もしかしたら送信時間が実時間制御側の周期をこえてしまっているのかもしれません。
@n-andoさんにお教えいただいている条件ですと、
publisherスレッドの送信にかかる時間を現状の構成になってからこちらで測定してないのでしようと思うのですが、
現状の条件は
周期250hz
接続しているデータポートのポート数は29個
上記29個の総計データ量は2412バイトほどで、型での内訳はdoubleが254個、longが 93個、boolが 8個(TimedXXXなど含め)
となっており、データ数・ポート数が多いのかもしれません。
ちなみに、データポートの通信で、同じデータ量でも
小さいデータ型をたくさんのポートで通信
大きいデータ型を少ないポートで通信
を比較すると、後者の方がよかったりすることもありますでしょうか。
データ自体のオーバーヘッドもありそうですが、今回のケースのように
データポート1個につき1つのpublisherスレッドなので、
後者のほうがスレッドのmutexのかかるタイミングもへったりしますでしょうか。
</pre>
バグ #3438 (新規): hrpsys-base の rtm.py::reeadDataPort() を呼ぶと disconnect() で稀に落ちる
https://www.openrtm.org/redmine/issues/3438
2016-01-28T19:53:03Z
n-ando
Noriaki.Ando@gmail.com
<p><a class="external" href="https://github.com/fkanehiro/hrpsys-base/issues/905">https://github.com/fkanehiro/hrpsys-base/issues/905</a></p>
バグ #3251 (新規): Windows用のcoil_config.h の記述がいろいろと変(Linux用のヘッダになっている)
https://www.openrtm.org/redmine/issues/3251
2015-07-06T03:15:11Z
n-ando
Noriaki.Ando@gmail.com
<p><a class="external" href="http://svn.openrtm.org/OpenRTM-aist/trunk/OpenRTM-aist/src/lib/coil/win32/coil/config_coil.h">http://svn.openrtm.org/OpenRTM-aist/trunk/OpenRTM-aist/src/lib/coil/win32/coil/config_coil.h</a></p>
バグ #3088 (終了): idl ファイルの置かれているディレクトリにピリオドがあるとrtc-templateがおかしくなる
https://www.openrtm.org/redmine/issues/3088
2015-01-09T16:21:08Z
k-okada
k-okada@jsk.t.u-tokyo.ac.jp
<p>以下のようになります.このパッチで治るでしょうか?</p>
<p><a class="external" href="https://github.com/tork-a/openrtm_aist-release/blob/patches/release/indigo/openrtm_aist/0003-fix-for-idl-file-which-is-located-on-directory-conta.patch">https://github.com/tork-a/openrtm_aist-release/blob/patches/release/indigo/openrtm_aist/0003-fix-for-idl-file-which-is-located-on-directory-conta.patch</a></p>
<p>```<br />[ 72%] Building CXX object CMakeFiles/MyServiceROSBridgeComp.dir/src_gen/MyServiceROSBridge.cpp.o<br />/usr/lib/ccache/i686-linux-gnu-g++ -DROSCONSOLE_BACKEND_LOG4CXX -DROS_PACKAGE_NAME=\"openrtm_ros_bridge\" -g -O2 -fstack-protector --param=ssp-buffer-size=4 -Wformat -Werror=format-security -DNDEBUG -D_FORTIFY_SOURCE=2 -I/tmp/buildd/ros-indigo-openrtm-ros-bridge-1.2.7-0trusty-20150109-0739/obj-i686-linux-gnu/devel/include -I/opt/ros/indigo/include -I/opt/ros/indigo/include/coil-1.1 -I/opt/ros/indigo/include/openrtm-1.1 -I/opt/ros/indigo/include/openrtm-1.1/rtm/idl -o CMakeFiles/MyServiceROSBridgeComp.dir/src_gen/MyServiceROSBridge.cpp.o -c /tmp/buildd/ros-indigo-openrtm-ros-bridge-1.2.7-0trusty-20150109-0739/src_gen/MyServiceROSBridge.cpp<br />In file included from /tmp/buildd/ros-indigo-openrtm-ros-bridge-1.2.7-0trusty-20150109-0739/src_gen/MyServiceROSBridge.cpp:7:0:<br />/tmp/buildd/ros-indigo-openrtm-ros-bridge-1.2.7-0trusty-20150109-0739/src_gen/MyServiceROSBridge.h:32:61: fatal error: /tmp/buildd/ros-indigo-openrtm-ros-bridge-1Stub.h: No such file or directory<br /> #include "/tmp/buildd/ros-indigo-openrtm-ros-bridge-1Stub.h" <br />```</p>
バグ #3086 (終了): OutPort::writeがポートの接続時に遅くなる
https://www.openrtm.org/redmine/issues/3086
2014-12-06T17:56:10Z
k-okada
k-okada@jsk.t.u-tokyo.ac.jp
<p><a href="https://github.com/fkanehiro/hrpsys-base/issues/241" class="external">hrpsys-base</a> でも話題になっていますが、<br />OutPortのwriteメソッドがポートの接続などが行われているときに顕著に遅くなるようです。</p>
<p>OpenRTMの1.1.0を使っています。</p>
<p>具体的には、OutPort::writeの<br /><pre>
RTC::ConnectorProfile prof(findConnProfile(id));
</pre><br />の部分がよく遅くなるようです。</p>
<p>OutPort::writeはonExecute内で実時間コンテクストの中で呼び出しているので、<br />この問題が発生すると、実時間周期を守れなくなってしまいます。</p>
バグ #2808 (新規): ExtTrigExecutionContext, SynchExtTriggerEC の deactivate_component() を修正する
https://www.openrtm.org/redmine/issues/2808
2013-08-27T01:28:40Z
n-ando
Noriaki.Ando@gmail.com
<p>中岡さんから以下の様な報告があったので調査して反映させる。</p>
<pre>
産総研の中岡です。
以前静岡大の清水さんが本MLにポストされた02356の投稿を見つけたのですが、
そこでSynchExtTriggerECのdeactivate_component()の挙動に関する指摘があり
ました。
具体的にはExtTrig系のECでは deactivate_component()内にてtick()を行わない
と、状態遷移が行われずにタイムアウトするまで処理がブロックしてしまうとい
うものです。
これについてはバージョン1.1.0-RC3に関する指摘だったようなのですが、
1.1.0-RELEASEについても修正がされていないようです。
実は開発中のChoreonoidでRTCを用いたシミュレーションを行なっていると、
コンポーネントのdeactivate時に一定の時間固まる症状が出まして、
これをなんとかしたく思って上記の投稿を見つけた次第です。
(Windowsだと場合によってはRTCひとつをdeactivateするのに何秒も固まってし
まいます…。)
とりあえずChoreonoidにおいて以下のようなdeactivate_componentをもつECを
作って動かしたところ、固まる症状がなくなりました。
RTC::ReturnCode_t
ChoreonoidExecutionContext::deactivate_component(RTC::LightweightRTObject_ptr
comp) throw (CORBA::SystemException)
{
RTC_TRACE(("deactivate_component()"));
CompItr it = std::find_if(m_comps.begin(), m_comps.end(),
find_comp(comp));
if(it == m_comps.end()) {
return RTC::BAD_PARAMETER;
}
if(!(it->_sm.m_sm.isIn(RTC::ACTIVE_STATE))){
return RTC::PRECONDITION_NOT_MET;
}
it->_sm.m_sm.goTo(RTC::INACTIVE_STATE);
tick();
if(it->_sm.m_sm.isIn(RTC::INACTIVE_STATE)){
RTC_TRACE(("The component has been properly deactivated."));
return RTC::RTC_OK;
}
RTC_ERROR(("The component could not be deactivated."));
return RTC::RTC_ERROR;
}
ただ、やはりOpenRTM-aist本体でこの修正がなされていることが望ましいので、
今後のリリースで修正をお願いできますでしょうか(ExtTrigExecutionContext,
SynchExtTriggerECの両方にしておくべきかと思います。)
以上よろしくお願い致します。
</pre>
バグ #2807 (新規): coil/Routing.cpp のwait(NULL)は不要
https://www.openrtm.org/redmine/issues/2807
2013-08-27T01:26:41Z
n-ando
Noriaki.Ando@gmail.com
<p>coil/Routing.cpp (posix版) 内で子プロセス終了を待つために wait(NULL) が数か所あるが、wait自体はpclose内に含まれているので不要</p>
<pre>
産総研の中岡です。
度々すみません、Mac OS X (Lion) においてマネージャ初期化時に固まるという
不可解な症状に遭遇しましたので、報告させてください。
状況としては、Choreonoidにおいて起動時にRTC::Manager::init()を行なってお
り、ある条件下でこの関数が固まります。
固まる箇所をたどっていくと、
Manager::initNaming() -
NamingManager::registerNameServer()-
NamingManager::createNamingObj() -
NamingOnCorba::NamingOnCorba() -
coil::dest_to_endpoint()
ときて、ここから呼ばれる
coil::find_dest_ifname() と
coil::ifname_to_ipaddr() の関数です。
1.1.0-RELEASEのsrc/lib/coil/posix/coil/Routing.cppにおいて、
108行と107行にある
wait(NULL)
でブロックしたまま帰ってきていません。
ある条件というのは、マネージャの初期化を行なっているプロセスから、
マネージャ初期化の前にネームサーバのコマンドを(別プロセスとして)起動し
ているということです。同じコマンドをあらかじめ他のプロセスから起動してあ
る場合は、問題なく動くのですが…。また、この症状が出るのはOS Xだけで、
WindowsやLinuxでは同じ事を行なっても問題なく動いています。
そして、OS Xでも上記の2つのwait(NULL)をどちらもコメントアウトすると、固
まらなくなり、その後も特に問題なく動いているように見えます。
ちなみにネームサーバのコマンドはomniNamesを参考に自前で実装した
Choreonoid付属のものです。WindowsやMacではネームサーバがデーモンとして自
動では起動しないのが普通だと思いますが、そのような場合でもChoreonoidを起
動するだけで簡単にシミュレーションを行えるように、この機能をつけています。
以上のような症状なのですが、今後のリリースで上記のwait(NULL)を除去しても
らうというのは問題ありますでしょうか?
</pre>
バグ #2802 (新規): rpi.shのgitがProxy環境下ではうまく動かない
https://www.openrtm.org/redmine/issues/2802
2013-08-14T09:09:31Z
n-ando
Noriaki.Ando@gmail.com
<p>(独)産業技術総合研究所<br />知能システム研究部門<br /> 安藤 慶昭 様</p>
<p>いつもお世話になっております。<br />ウィン電子工業の片見です。</p>
<p>PiRT-Unitを購入して頂いたお客様(首都大東京様)が<br />OpenRTM+PiRT-Unitでシステム構築をされています。</p>
<p>そのお客様は、<br />OpenRTMサイトを参考にされており、<br />セットアップスクリプト(rpi.sh)について<br />報告がありました。</p>
<p>rpi.sh の実行中に<br />git clone のエラーが発生したようです。<br />error: server certificate verification failed.</p>
<p>これは、校内のネットワーク環境(プロキシー)に依存して<br />発生するようです。<br />#弊社の環境では、<br />#再現しませんでした。</p>
<p>解決方法としては、<br />CA verificationを無効にすると<br />解決するとのことです。<br /> $sudo -s<br /> #git config --global --add http.sslVerify false</p>
<p><a class="external" href="http://psychomotorcycle.blogspot.jp/2011/07/proxygit-clone.html">http://psychomotorcycle.blogspot.jp/2011/07/proxygit-clone.html</a><br /><a class="external" href="http://codeblue.umich.edu/index/projects/codeblue/wiki/FAQ#The-requested-URL-returned-error-401-when-cloning-a-git-repository">http://codeblue.umich.edu/index/projects/codeblue/wiki/FAQ#The-requested-URL-returned-error-401-when-cloning-a-git-repository</a></p>
<p>お客様から、<br /> rpi.sh のバグではないのですが、<br /> さしつかえなければ、<br /> <a class="external" href="http://openrtm.org/openrtm/ja/content/system_setup_pirtunit">http://openrtm.org/openrtm/ja/content/system_setup_pirtunit</a><br /> に、対策を記載した方がよいのでは。<br />とお話しを頂きました。</p>
<p>注意書きのような形で<br />「error: server certificate verification failed.」が<br />発生した場合は、以下を実行してみてください。<br /> $sudo -s<br /> git config --global --add http.sslVerify false</p>
<p>弊社で再現しなかったので、<br />ちゃんと確認できたいのですが、<br />お時間あるときで結構ですので、<br />記載の検討をお願いいたします。</p>
<p>よろしくお願いいたします。</p>
バグ #2567 (新規): coilの.pcファイルが64bitの時機能しない
https://www.openrtm.org/redmine/issues/2567
2013-01-14T14:55:42Z
n-ando
Noriaki.Ando@gmail.com
<p>coilの.pcファイルが64bitの時機能しない</p>
バグ #2560 (新規): バッファやコネクタまわりに関しての改善・検討要望
https://www.openrtm.org/redmine/issues/2560
2013-01-07T01:20:35Z
n-ando
Noriaki.Ando@gmail.com
<p>静岡大の清水です。</p>
<p>バッファやコネクタまわりに関しての改善・検討要望です。<br />過日のSI2012で発表した、共有メモリベースの<br />データ通信機能を実装する際に問題となった点です。<br />ご検討頂ければ幸いです。</p>
<p>【問題点】<br />現行のコネクタの実装(InPortPushConnectorを例とします)では、<br />以下の手順で初期化(コンストラクタ内で)がされています。</p>
<p>(1) バッファ生成<br />(2) プロバイダの初期化(InPortProvider::init()のコール)</p>
<p>一般に、プロバイダ(コンシューマも)は特定のバッファとの組み合わせでしか<br />動作しない場合も考えられると思います。<br />すなわち、プロバイダがどのバッファを生成するかを制御できる必要があります。</p>
<p>どのバッファを生成するかは、ConnectorProfileにbuffer_typeを設定することで<br />制御できますが、もしユーザが間違ったbuffer_typeを指定した場合、<br />あるいは何も指定しなかった場合は、プロバイダに適合したバッファが生成されません。</p>
<p>【対応策】<br />この問題は、バッファの生成とプロバイダの初期化の順序を入れ替えることで<br />回避できます。私が実際に変更したコードは以下です。</p>
<p>・オリジナル(一部のみ抜粋)<br />InPortPushConnector(ConnectorInfo info, InPortProvider *provider)
{<br /> m_buffer = createBuffer(info);<br /> m_buffer->init(info.properties.getNode("buffer"));<br /> m_provider->init(info.properties);<br /> m_provider->setBuffer(m_buffer);<br /> m_provider->setListener(info, &m_listeners);<br />}</p>
<p>・変更後<br />InPortPushConnector(ConnectorInfo info, InPortProvider *provider)
{<br /> m_provider->init(info.properties); //<= バッファ生成前にプロバイダのinit()をする<br /> m_buffer = createBuffer(info);<br /> m_buffer->init(info.properties.getNode("buffer"));<br /> m_provider->setBuffer(m_buffer);<br /> m_provider->setListener(info, &m_listeners);<br />}</p>
<p>以上のように変更し、自作プロバイダのinit()内でbuffer_typeプロパティを<br />追加(または上書き)すれば、プロバイダがバッファの種類を完全に制御できます。</p>
<p>ところで、プロバイダのinit()の引数がconst指定になっていないのは、<br />プロバイダがConnectorProfileの情報(コピー)を書き変えても良いということだと、<br />私は判断しましたが、それで問題ないですよね。<br />もし書き換えを許可しないなら、const指定とする必要があります。</p>
<p>以上、よろしくご検討をお願いいたします。</p>