Legacy Issue Number: 3672
Source: International Business Machines ( Phil Adams)
I am in the process of implementing Portable Interceptors within a C++
and I would like to raise an issue for resolution regarding the semantics
"register_initial_reference()" function, particularly with respect to the
management of the object being registered.
The interface for this function is as follows:
void register_initial_reference (
Within the Portable Interceptors specification, there is really no
how the memory for the object should be managed. For example, does the
"register_initial_reference()" pass ownership of the object to the ORB, or
Also, does the caller of "resolve_initial_references()" gain ownership of
which is returned, or not?
Here is my proposed resolution:
The fact that the "obj" parameter is a CORBA::Object implies that it is a
object. Therefore, it would make sense that when
"register_initial_reference()" is called, the
ORB performs a "_duplicate()" on the object to increment its reference
count (the ORB would
then hold its own reference count). The caller of
"register_initial_reference()" can decide
whether to call "release()" or retain its own reference count.
Later, when "resolve_initial_references()" is called, the ORB would call
"_duplicate()" on the
object prior to returning it to the caller, thereby giving the caller its
own reference count.
The caller would then need to call "release()" when it is finished with
When the ORB is deleted, it must clean up the lookup table of registered
objects. To do this,
it simply calls "release()" on each one, and if no one else holds a
reference count, then
the object is simply deleted.
I would like the hear other people's thoughts on this, particularly those
who have done or are
working on a C++ implementation of PI.
Reported: CPP 1.1 — Tue, 6 Jun 2000 04:00 GMT
Disposition: Resolved — CORBA 3.0.2
Updated: Fri, 6 Mar 2015 20:58 GMT
CORBA3 — Portable Interceptors / register_initial_reference()
- Key: CORBA3-15
- OMG Task Force: Core 2002 RTF