[openrtm-users 00818] Re: SdoConfiguration のデストラクタ

[Ando Noriaki]

清水様

安藤です


> Configurationクラスは外部にexportして、
> ユーザが自由に使ってもよいものではないのでしょうか。
> もし、RTMの内部利用のみなら上記のような制約でも
> 問題ないと思いますが、外部exportしていて、
> ユーザにどう利用されるか分からないと仮定すると、
> 「deleteする前に必ずdefaultPOAでdeactivate
> しなければならない」という制約での
> 実装は危険だと感じます。

SdoCondigurationクラスは、ConfigAdminクラスと一緒に使うように
できているので、その辺を了解しているひとなら使えると思いますが、
今のところ他のユーザがそれらを単独で使うようには考慮していません。

Configurationは
・コンポーネント作成者からはあくまで、単なる変数へのアクセス
・外部からはSDOPackage::Configurationインターフェースからのアクセス
　（しかも、SDOが保持しているという前提）
という前提になっています。

> デストラクタの実装は私も非常に気を使うのですが、
> このクラスの場合、defaultPOAでdeactivateさえ
> しておけば、deleteされても問題ないと思います。
> もし、deleteされる前にdeactivateされていた
> 場合でも問題ないように、
> deactivateの一連の処理をtry catch節で括っています。
> CORBA仕様では、deactivate済みのオブジェクトのservant_to_id()
> は例外を投げることになっているので、
> そうしておけば常に安全にdeactivateされると
> 考えたからです。
>
>
>> そうですね、RTObjectのshutdown内でのdeactivateでManager
> から
>> もらったPOAでdeactivateをしているのでこれは問題になる
> かもしれません。
>>
>> ところで、defaultでないPOAを使いたい場面とか、なにかあ
> りますか。
>> あるようなら、独自のServantBaseを実装してもよいのです
> が。。。
>
> 現在のところは必要ありませんが、将来の拡張性や
> メンテナンス性を考えての意見です。
> 万一、ManagerのPOAがデフォルトでなくなった場合でも、
> RTMのソース全体を見渡してPOAを逐一変更しなければ
> ならないとなるとデバッグも大変なので、
> そういう場合に備えてはどうでしょうか、ということです。

doilでは、いずれこの辺のコードはなくなってしまうか、自動生成する
ともりだったので、汚いけど放置してました。
どうするか今後検討させていただきます。
-- 
安藤慶昭＠独立行政法人産業技術総合研究所 研究員
                  知能システム研究部門 統合知能研究グループ
                  〒305-8568 茨城県つくば市梅園1-1-1 中央第2
                  TEL: 029-861-5981 FAX: 029-862-6631
                  n-ando ＠ aist.go.jp, n-ando ＠ ieee.org