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

Jeff Squyres (jsquyres) jsquyres at cisco.com
Tue May 21 08:41:38 CDT 2013


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


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




More information about the discuss mailing list