itaps-parallel technical issues in iMeshP.h

[Tim Tautges]

IMO, the argument should be passed as an "in" argument, consistent with 
the dtor function to destroy the imesh instance.

- tim

Devine, Karen D wrote:
> 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
>>
>>
> 
> 
> 
> 

-- 
================================================================
"You will keep in perfect peace him whose mind is
   steadfast, because he trusts in you."               Isaiah 26:3

              Tim Tautges            Argonne National Laboratory
          (tautges at mcs.anl.gov)      (telecommuting from UW-Madison)
          phone: (608) 263-8485      1500 Engineering Dr.
            fax: (608) 263-4499      Madison, WI 53706