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

[Jeff Squyres (jsquyres)]

Ah.  Well.  There you go.  :-)

I'd say that all these keyval things are worthy of discussion in SJC... (fortran included!)


On May 21, 2013, at 9:44 AM, Pavan Balaji <balaji at mcs.anl.gov>
 wrote:

> 
> 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


-- 
Jeff Squyres
jsquyres at cisco.com
For corporate legal information go to: http://www.cisco.com/web/about/doing_business/legal/cri/