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

Masayuki Shimizu masayuki.shimizu @ aist.go.jp
2009年 5月 29日 (金) 12:29:31 JST


安藤様

> SdoConfigurationのdeactivateはRTObjectのshutdownの中で
行っています。
> SdoConfigurationの寿命はRTObjectの寿命以下なので、
> とりあえずこれでも問題ないと思います。
> コンストラクタの中で、activateしているので、デストラク
タの中で
> deactivateするのが筋かとは思いますが。

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

デストラクタの実装は私も非常に気を使うのですが、
このクラスの場合、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を逐一変更しなければ
ならないとなるとデバッグも大変なので、
そういう場合に備えてはどうでしょうか、ということです。

清水



openrtm-users メーリングリストの案内