[ciao-users] Update: [CIAO] [questions on lack of _duplicate in a component's auto-generated reactor() method, etc...]
King, Perry (ES)
perry.king at ngc.com
Thu Nov 3 14:29:20 CDT 2016
So after sending this original e-mail, I found some of the auto-generated code for the get_connection_* calls and it is calling _duplicate on the return value which then means the caller would need to place it into a _var type or call release explicitly. I don't have to source handy for the calls that reactor() is making, but I'm guessing they are also doing the same thing.
So is this the general pattern followed in the CIAO layer to always call _duplicate on any returned object references?
Thanks,
Perry King
From: King, Perry (ES)
Sent: Thursday, November 03, 2016 2:48 PM
To: 'ciao-users at list.isis.vanderbilt.edu' <ciao-users at list.isis.vanderbilt.edu>
Subject: [CIAO] [questions on lack of _duplicate in a component's auto-generated reactor() method, etc...]
CIAO VERSION: 1.3.2
TAO VERSION : 2.3.2
ACE VERSION : 6.3.2
HOST MACHINE and OPERATING SYSTEM:
Intel core I7 4-core Ivy bridge based PC, Centos 6.5
If on Windows based OS's, which version of WINSOCK do you
use?: N/A
TARGET MACHINE and OPERATING SYSTEM, if different from HOST:
COMPILER NAME AND VERSION (AND PATCHLEVEL): Same
THE $ACE_ROOT/ace/config.h FILE [if you use a link to a platform-
specific file, simply state which one]:
#ifndef SNA_ACE_CONFIG_H
#define SNA_ACE_CONFIG_H
// Turn off default DNS lookup
#define TAO_USE_DOTTED_DECIMAL_ADDRESSES 1
// Turn on in-memory growable notification queue
#define ACE_HAS_REACTOR_NOTIFICATION_QUEUE 1
// Turn on "best" collocation strategy as default
#define TAO_DEFAULT_COLLOCATION_STRATEGY TAO_COLLOCATION_BEST
// Preestablish all CORBA connections during startup
// TODO: Pre-establishment of connections is broken
//#define CIAO_PRE_ESTABLISH_CONNECTIONS 1
// Turn on immediate symbol resolution
#define ACE_DEFAULT_SHLIB_MODE RTLD_NOW | RTLD_GLOBAL
// Use monotonic clock
#define ACE_HAS_CLOCK_GETTIME_MONOTONIC 1
// Turn on high-resolution/monotonic clock in TAO, CIAO, and DAnCE by default
#define TAO_USE_HR_TIME_POLICY_STRATEGY 1
#include "ace/config-linux.h"
#endif
THE $ACE_ROOT/include/makeinclude/platform_macros.GNU FILE [if you
use a link to a platform-specific file, simply state which one
(unless this isn't used in this case, e.g., with Microsoft Visual
C++)]:
Not sure which one is used, but shouldn't matter for my question
CONTENTS OF $ACE_ROOT/bin/MakeProjectCreator/config/default.features
(used by MPC when you generate your own makefiles):
ace_idl_dependencies = 1
boost = 0
ccm_direct_collocation = 1
ccm_lw = 1
ccm_noevent = 1
dds4ccm_ndds = 1
gen_ostream = 0
install_rpath = 0
ndds = 1
optimize_collocated_invocations = 1
stl = 1
xerces2 = 1
AREA/CLASS/EXAMPLE AFFECTED:
N/A
DOES THE PROBLEM AFFECT:
COMPILATION?
N/A
LINKING?
N/A
EXECUTION?
N/A
OTHER (please specify)?
N/A
SYNOPSIS:
Usage of CORBA::ORB_var orb in a component's auto-generated reactor() method)
DESCRIPTION:
The following code is auto-generated for a component's reactor() method:
ACE_Reactor * reactor = 0;
CORBA::Object_var ccm_object = this->ciao_context_->get_CCM_object();
if ( ! CORBA::is_nil(ccm_object.in()))
{
CORBA::ORB_var orb = ccm_object->_get_orb ();
if ( ! CORBA::is_nil(orb.in()))
{
reactor = orb->orb_core ()->reactor ();
}
}
...
Questions:
1. Since when it goes out of scope, CORBA::Object_var decrements the reference
count and releases the resource when it counts down to zero, why doesn't there
need to be a call to a _duplicate method on what is returned from the
get_CCM_object() and reactor() calls?
2. For a component's port that is typed to a DDS4CCM connector If you are using an
"_var" variable to hold the result from a get_connection_<port>_<basic port>() call,
is it correct to use _duplicate to ensure the object held in the ciao_context_ is
not prematurely freed?
3. Is it also required that _duplicate be used on similar get_connection_... calls for a CORBA client port?
REPEAT BY:
N/A
SAMPLE FIX/WORKAROUND:
N/A
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://list.isis.vanderbilt.edu/pipermail/ciao-users/attachments/20161103/0ca0ae94/attachment-0001.html>
More information about the ciao-users
mailing list