[MOAB-dev] [patch] Remove entity sets from counts for iMesh_getNumOfType/Topo

[Jason Kraftcheck]

Jed Brown wrote:
> On Mon 2008-10-06 16:17, Jason Kraftcheck wrote:
>> 0001-Closed-a-memory-leak-in-ReadParallel-due-to-unresolv.patch
>>  - Not applied: It is typical for an application to keep its MBParallelComm
>>     instance for the life of the application, even if that instance is
>>     created from default values when the file is read in.  So a) this change
>>     breaks existing code that expects to be able to query the MBParallelComm
>>     instance used during file import and b) is not that serious of an issue
>>     because the instances are usually kept anyway.  This will be fixed
>>     eventually, but a correct fix is much more complicated.
> 
> Thanks for the explanation.  I made this naive change because valgrind
> was warning about this while I was debugging some of my own code.  I
> suppose you want to eventually either have reference counting in
> MBParallelComm or use a shared pointer?
> 

I was hoping to eventually get rid of the persistent nature of the
MBParallelComm instances, and instead represent all data for a given
partitioning of the mesh using the MOAB data model (e.g. entity set
representing partitioning, with child sets representing parts, and children
of those sets representing interfaces.)  And then make MBParallelComm a
simple utility class that can be created and destroyed by whatever function
is using it:
  MBEntityHandle partition;
  ...
  MBParallelComm comm_tool(partition);
  ...

But if a short term solution is necessary, we can probably provide some
mechanism other than a tag array in which to store "utility" class instances
 in MBCore, provide an abstract interface to avoid making MBCore depend on
the parallel code, and then have MBCore destroy all registered utility
classes in its destructor.

- jason