itaps-parallel technical issues in iMeshP.h

[Devine, Karen D]

Despite what any of us prefer for deletion and destruction routines, we
should make iMeshP_destroyPartitionAll's behavior consistent with the rest
of iMesh.  Let me know what's consistent, and that's what we will do.

Karen


On 10/6/08 1:44 PM, "Jason Kraftcheck" <kraftche at cae.wisc.edu> wrote:

> Devine, Karen D wrote:
>>
>>
>>> On 10/3/08 12:20 PM, "Jason Kraftcheck" <kraftche at cae.wisc.edu> wrote:
>>>> Devine, Karen D wrote:
>>>>> On 10/2/08 3:46 PM, "Jason Kraftcheck" <kraftche at cae.wisc.edu> wrote:
>>>>> iMeshP_destroyPartitionAll
>>>>>   - Why is 'partition_handle' inout?  What is this function returning
>>>>>     a handle to?  Some other partition?
>>>> The partition handle should be set to an invalid value when we destroy the
>>>> partition.
>>>>
>>> Why do we do this for partition handles, and not for any other type of
>>> handle?  E.g.:
>>>   iMesh_deleteEnt
>>>   iMesh_deleteEntArr
>>>   iMesh_destroyTag
>>>   iMesh_destroyEntSet
>>>   iMesh_endEntIter
>>>   iMeshP_destroyPart
>>> and for that matter:
>>>   free
>>>   delete
>>>   fclose
>>>   etc.
>>
>> Actually, I would ask why ITAPS doesn't invalidate handles for other types
>> of deletions (as in the list above).  As a user, I'd like to have a handle
>> invalidated when it is no longer valid, so that I couldn't misuse it later.
>
> For that to be useful, it requires the assumption that the application has
> no more than one copy of the handle in question.  And when that is true, it
> is rather trivial to set the handle to an invalid value after calling the
> 'destroy' function.
>
>> And, yes, I wish "free" set its pointer argument to NULL after freeing
>> memory.  So the true answer to your "why" question is that *I* wrote this
>> section of iMeshP instead of other ITAPS people.  :)
>>
>> Your example below is good, but in a C environment where users have to
>> destroyPartition themselves, I think invalidating the handle is a good idea.
>> In your example, you wouldn't have to send a temporary pointer to
>> destroyPartition; you would only have to remove the "const" definition.
>
> But that's exactly my point: I'd have to modify an unrelated part of my code
> (the 'const') to use this function for no reason other than so that the
> function can "invalidate" a variable that is about to be destroyed anyway.
>
>>  The
>> call to createPartition modifies the partition handle as well.  Wouldn't
>> your class' constructor have to call createPartition?  If not, from where
>> does the constructor get the partition handle?
>
> Does it matter where it comes from?  Presumably it comes from some code that
> does the partitioning, which is a bit to complex to put in a constructor.  I
> can just as easily provide an example where the destructor doesn't destroy
> the handle:
>
>   class Partition {
>   public:
>      Partition( iMeshInstance instance, iMeshP_PartitionHandle handle )
>        : myHandle(handle), myiMesh(instance) {}
>
>      iMeshP_PartitionHandle get_handle() const
>         { return myHandle; }
>
>      iMeshInstance get_mesh() const
>         { return myiMesh; }
>
>      private:
>         const iMeshP_PartitionHandle myHandle;
>         const iMeshInstance myiMesh;
>    };
>
>
> Now the management of the partition handle is "consistent" in that the
> constructor does not allocate it and the destructor does not release it.
> However, how I have to make a copy of the handle in the code that does
> release the handle because I cannot do something like this:
>
>   iMeshP_destroyPartitionAll( ptn.get_mesh(), ptn.get_handle(), &err );
>
>
> - jason
>
>