[MWy] Ukol CORBA

[Petr Tůma]

Dobry den,

standardni postup je vytvaret instanci servantu pomoci 
CORBA::make_reference<instance_impl> (mapovani pro C++11 vyslovne rika, 
ze se nesmi delat new a delete na servant classes, volani 
std::make_unique podle meho nazoru do tohoto patri, protoze to je 
template, ktera neni implementovana CORBOU a uvnitr ni se nakonec stejne 
to new vola).

Takze ve vasem kodu byste nejspis delal neco jako:

instance_ = CORBA::make_reference<instance_impl>(...);
return instance_->_this();

Tohle bude mit soucasne za nasledek to, ze se objekt zaregistruje v mape 
aktivnich objektu uvnitr POA (side efekt volani _this() pri policy 
IMPLICIT_ACTIVATION, na prednasce bude az dneska :-). Pro nazornejsi 
predvedeni funkce je mozna misto volani _this() lepsi explicitni volani 
POA::activate_object(), ale to je delsi kod :-).

Smart pointer vraceny CORBA::make_reference() ma semantiku 
std::shared_ptr, takze pri dalsim prirazeni do instance_ se predchozi 
servant nebude mazat (je jeste registrovany v mape aktivnich objektu). 
Skutecne smazani by pak probehlo teprve az objekt vyjmete z mapy 
aktivnich objektu (a zrusite na nej vasi lokalni referenci), coz lze 
ucinit volanim POA::deactivate_object() (coz by melo jit udelat uvnitr 
metody instance_impl::disconnect(), protoze POA by mel behem volani 
udrzovat referenci nazivu, ale v C++11 jsem to jeste netestoval).

Volani CORBA::release() je relikt z C++, standardni postup pro C++11 by 
byl pouzit na klientovi jako referenci typ IDL::traits<...>::ref_type, 
ktery reference counting zaridi automaticky.

Petr Tuma


On 23/03/16 01:12, Petr Stefan wrote:
> Dobry den,
>
> narazil jsem na problem pri implementaci serveru v druhem domacim ukolu.
> Klient mi funguje v poradku a mam implementovanou i vetsinu serveru,
> pouzivam TAOX11. Metoda connect() na implementaci rozhrani server_i
> (oznacme si ji server_impl) vraci referenci na instanci nejake tridy,
> ktera implementuje rozhrani instance_i (tu si oznacme instance_impl). To
> znamena, ze server musi v teto metode vytvorit novou instanci tridy
> instance_impl a vratit referenci ziskanou metodou _this(). Ale je treba
> zajistit, aby instance vraceneho objektu existovala dostatecne dlouho.
> Proto jsem zacal s tim, ze se vzdy bude pripojovat pouze jeden klient,
> na ktery si budu udrzovat v server_impl odkaz (std::unique_ptr). Pokud
> pak v metode server_impl::connect() provadim kod:
>
> instance_ = std::make_unique<instance_impl>(peer, key);
> return instance_->_this();
>
> tak prvni spusteni klienta probehne v poradku, ale pri druhem spusteni
> server z niceho nic v tomto miste spadne na segmentation fault. Coz mi
> samo o sobe prijde divne, protoze pouzivam chytre ukazatele abych vzdy
> pracoval s pameti spravne. Tento kod by vlastne mel vytvorit novy
> inicializovany unique_ptr, ktery se move semantikou priradi do privatni
> promenne instance_, cimz se provede automaticka dealokace puvodniho
> objektu. Nevite, cim by to mohlo byt toto divne chovani zpusobeno?
> Jiste reseni by mohlo byt ukladat si jednotlive instance do nejakeho
> kontejneru v server_impl (napr. std::vector), ale tam vznika problem s
> mazanim instanci - metoda disconnect() je na instance_i a ne server_i,
> tudiz se tato instance nemuze sama odebrat z kolekce v server_impl. Jak
> takovou vec resit, popripade poskytuje CORBA primo nejake prostredky? Me
> by nyni prislo logicke presunout metodu disconnect() z rozhrani
> instance_i do server_i, ale to s sebou prinasi drobne nevyhody jako
> nutnost rozpoznavat jednotlive instance podle unikatnich ID atd.
>
> Takze pro shrnuti: Jak zajistit zivotnost objektu instance_impl? Jak je
> dealokovat pomoci jejich vlastni metody disconnect()?
>
> Jeste jedna otazka na zaver: je nutne v klientovi na ziskane instanci
> pri ukoncovani zavolat CORBA::release() po poslednim volani, tj. po
> instance->disconnect()?
>
> S pozdravem,
> Petr Stefan
>
> _______________________________________________
> MWy mailing list
> MWy at d3s.mff.cuni.cz
> https://d3s.mff.cuni.cz/mailman/listinfo/mwy