> CIAO Version: 0.5.6 (SVN-HEAD)
> 
> Hi folks,
> 
> I'm going through some of the DAnCE code to understand what it is doing.
> I remember when I was reading Doug's book (C++ NP) that it said 
> something like the following:
> 
> "On platforms such as Windows, memory allocated by a DLL must be 
> deallocated by the SAME DLL." I'm right here, is that still the case?

Yes, that's correct.

> My question is motivated the following code snippet. We open a DLL 
> "CIAO_NA_Configurator", we use its factory function 
> "create_na_config_manager" to dynamically allocate an object.
> CIAO_NA_Configurator dynamically allocated that object, the class 
> below (which resides in a different DLL) deallocates this memory 
> (which is being held by an auto_ptr).
> 
> int
> CIAO::NodeApp_Configurator::create_config_managers (void) {
>   typedef CIAO::Config_Manager * (*na_intelligent_designer)(void);
>   CIAO::Config_Manager* ptr = 0;
> 
>   int retval = this->config_dll_.open (
>                   ACE_DLL_PREFIX ACE_TEXT ("CIAO_NA_Configurator"),
>                   ACE_DEFAULT_SHLIB_MODE,
>                   0);
> 
>   // Cast the void* to non-pointer type first - it's not legal to
>   // cast a pointer-to-object directly to a pointer-to-function.
>   void *void_ptr =
>     this->config_dll_.symbol (ACE_TEXT ("create_na_config_manager"));
>   ptrdiff_t tmp = reinterpret_cast<ptrdiff_t> (void_ptr);
> 
>   // "id" is for na_intelligent-designer.
>   na_intelligent_designer config_id =
>     reinterpret_cast<na_intelligent_designer> (tmp);
> 
> 
>   ptr = config_id ();
> 
> 
>   this->na_config_manager_.reset (ptr); }

Gan/Will, can you guys please take a look at this?  We may need to implement 
some sort of "gobbler" function to clean this up.  Please see the examples in 
the ACE Service Configurator framework.

Thanks,

        Doug

Douglas C. Schmidt <schmidt@dre.vanderbilt.edu> writes:

> > "On platforms such as Windows, memory allocated by a DLL must be 
> > deallocated by the SAME DLL." I'm right here, is that still the case?
>
> Yes, that's correct.

Actually, it depends on the type of runtime your application and DLL are 
linked to. If it is static then your DLL and App each get a separate heap and 
you have to free the memory in the same place you've allocated it. On the 
other hand, if you are linking to the DLL runtime then both your DLL and App 
share the same heap and the place where you free the memory does not matter.


hth,
-boris

Hi Boris,

> Actually, it depends on the type of runtime your application and DLL 
> are linked to. If it is static then your DLL and App each get a 
> separate heap and you have to free the memory in the same place you've 
> allocated it. On the other hand, if you are linking to the DLL runtime 
> then both your DLL and App share the same heap and the place where you 
> free the memory does not matter.

Hum, that's not consistent with our experience.  I believe we've run into 
problems for the DLL runtime case.

Thanks,

        Doug

Hi Boris,

So basically, since CIAO infrastructure can't make assumptions about which run-
time the application is linked to, it has to do something like what the 
Service Config does with gobbler functions to insure that the DLL that 
allocated the memory would be the one that frees it.

Alternatively, if were willing to include the header file, we can use 
something like the ACE_ALLOC_HOOK that will provide class specific new/delete, 
that will insure allocation/deallocation is done in the same DLL.

Thanks,
Abdul 

Hi Doug,

Douglas C. Schmidt <schmidt@dre.vanderbilt.edu> writes:

> > Actually, it depends on the type of runtime your application and DLL 
> > are linked to. If it is static then your DLL and App each get a 
> > separate heap and you have to free the memory in the same place 
> > you've allocated it. On the other hand, if you are linking to the 
> > DLL runtime then both your DLL and App share the same heap and the 
> > place where you free the memory does not matter.
>
> Hum, that's not consistent with our experience.  I believe we've run 
> into problems for the DLL runtime case.

Well, the only reason why it may differ from your experience is if you are 
using Win32 heap allocation functions instead of C malloc/free or
C++ new/delete. Here is a post that explains this in a bit more detail:

http://blogs.msdn.com/oldnewthing/archive/2006/09/15/755966.aspx


I think this is also the reason why CIAO works even though it allocates and 
frees memory in different places.


hth,
-boris

Hi Abdul,

Sowayan, Abdullah (N-DUA) <abdullah.sowayan@lmco.com> writes:

> So basically, since CIAO infrastructure can't make assumptions about 
> which run-time the application is linked to, it has to do something 
> like what the Service Config does with gobbler functions to insure 
> that the DLL that allocated the memory would be the one that frees it.

Yes, though sometimes it is too much of a pain. But in case of CIAO I don't 
think there are any alternatives. In our code we pass an allocator object 
whenever a library (Xerces-C++ in our case) needs to allocate memory that we 
will be responsible for.


hth,
-boris