Re: [mpich-discuss] [PATCH v2] test: add attrdeleteget, MPI_Attr_get called from delete_fn
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 <[email protected]> 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 <[email protected]> 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 [email protected] For corporate legal information go to: http://www.cisco.com/web/about/doing_business/legal/cri/
participants (1)
-
Jeff Squyres (jsquyres)