[Mpi3-tools] MPI handles interface

John DelSignore jdelsign at totalviewtech.com
Tue Apr 21 08:29:20 CDT 2009


Ashley Pittman wrote:
> On Thu, 2009-04-16 at 17:31 -0400, Jeff Squyres wrote:
>> What about enums -- will those be problematic?  I tended to prefer  
>> enums in most places (vs. #define's) because a debugger can show those  
>> value names (when debugging this software itself -- not necessarily  
>> when in general use by a debugger for an MPI job).  If enums are going  
>> to be problematic, I can switch to #defines -- but it would be nice  
>> not to, if possible.
> 
> For reference the original code uses enums.
> 
>> The communicator "query" functions that I created start around line 649:
>>
>>      http://www.open-mpi.org/hg/hgwebdir.cgi/jsquyres/mpi3-tools-handles/file/4c5c1e7c0ef1/ompi/debuggers/mpihandles_interface.h#l649
>>
>> Could I get some comments on the group as to the general style of what  
>> I did?
> 
> The general style looks OK to me, without digging too far however I'm
> concerned about the idea of the DLL allocating memory and then having
> the debugger free it, this seems like a recipe for disaster to me.

I don't think this is a problem. In the existing message queue interface, "malloc" and "free" are callback functions that the debugger passes to the DLL. The DLL shouldn't call malloc or free directly. Instead, when the DLL need to alloc storage, it calls the malloc callback function which calls back into the debugger, and the debugger can implement the call back however it likes: C malloc, C++ new[], etc. When it comes time for the debugger to deallocate the block, it should use the matching function: C free, C++ delete[], etc. In practice, it all works out just fine.

Cheers, John D.


> I should be in the TelCon later all being well.
> 
> Ashley Pittman.
> 
> _______________________________________________
> Mpi3-tools mailing list
> Mpi3-tools at lists.mpi-forum.org
> http://lists.mpi-forum.org/mailman/listinfo.cgi/mpi3-tools
> 
> 



More information about the mpiwg-tools mailing list