[mpich-discuss] [PATCH v2] test: add attrdeleteget, MPI_Attr_get called from delete_fn

[Pavan Balaji]

It comes under "Groups, Contexts, Communicators, and Caching".  I'm
handling that as well.

 -- Pavan

On 05/21/2013 08:41 AM US Central Time, Jeff Squyres (jsquyres) wrote:
> FWIW: I don't know if attributes/callbacks are the purview of hybrid, but then again, I don't know exactly who's purview they fall under...
> 
> 
> On May 20, 2013, at 6:54 PM, Fab Tillier <ftillier at microsoft.com>
>  wrote:
> 
>> Pavan Balaji wrote on Mon, 20 May 2013 at 15:45:35
>>
>>>
>>> On 05/20/2013 11:16 AM US Central Time, Fab Tillier wrote:
>>>> In MPI-3, section 8.7.1 (page 363) states that delete callbacks are
>>>> invoked on MPI_COMM_SELF before anything else happens, and that
>>>> MPI_FINALIZED will return false from any of these delete callbacks.
>>>> There's no mention about attribute callbacks on other built-in
>>>> communicators, and no mention of behavior for built-in types.  Likely
>>>> they should be invoked too for consistency's sake.
>>>
>>> I'd think not.  For built-in communicators, it makes sense since they
>>> cannot be freed by the user.  For other communicators, it's the user's
>>> responsibility to free them.  So the callbacks should be triggered at
>>> that time.
>>
>> I meant for all built-in objects (communicators and types), not just MPI_COMM_SELF.  I agree that any user-allocated objects are the users's responsibility (just say no to automatic garbage collection).
>>
>>>> What's interesting is that this section states that there is an
>>>> ordering enforced (reverse from the order in which they are set),
>>>> while MPI_COMM_FREE (page 248) states that the callbacks are invoked
>>>> in arbitrary order.
>>>>
>>>> We should probably make that consistent, and to preserve backward
>>>> compatibility, the "arbitrary order" may have to become stricter for
>>>> implementations to match the finalize behavior.
>>>
>>> Gross.  Yes, I agree it should be consistent.
>>
>> I added some comments about the above to the ticket (https://svn.mpi-forum.org/trac/mpi-forum-web/ticket/374), as well as raised an issue about the keyval parameter value to the callbacks when the keyval has been freed by the user.
>>
>> Anyway, I think we're all converging on our opinions, which is always a good thing.
>>
>> Cheers,
>> -Fab
> 
> 

-- 
Pavan Balaji
http://www.mcs.anl.gov/~balaji