Re: [Mpi3-tools] Tools WG webex: tomorrow!
If there is a resource associated with the object, e.g., memory, you would not want to free it until the object was destroyed. MPI_xxx_FREE has the semantic effect of decrementing a reference count, not necessarily destroying the object. (Sorry if I'm missing the context - I was not on the call). Bill William Gropp Director, Parallel Computing Institute Deputy Director for Research Institute for Advanced Computing Applications and Technologies Thomas M. Siebel Chair in Computer Science University of Illinois Urbana-Champaign On Jul 1, 2013, at 12:33 PM, Jeff Squyres (jsquyres) wrote:
On Jul 1, 2013, at 1:24 PM, "David Goodell (dgoodell)" <[email protected]> wrote:
----8<----
• Jeff also brings up the idea of a callback (or some kind of MPI_T notification) to know when an MPI object is destroyed (per email conversation w/ Jeff, Kathryn, Martin). • Marc-Andre will think about whether it will be useful for any tools to know when MPI objects get destroyed. • Marc-Andre will also think about whether it would be useful for there to be an MPI_T mechanism to get some kind of unique ID for an MPI object (that will be durable after the handle is freed). This way, a tool can track the entire lifecycle of an object -- not just its handle. ----8<----
I was unable to attend the call, but why isn't attaching an attribute with a destructor callback to the object in question sufficient? Is it because we have MPI opaque objects which do not support attributes (e.g., MPI_Op)?
Today's attribute calls give you a callback when MPI_*_FREE is invoked -- when is potentially not when the object is actually destroyed.
The Fab+Jeff idea was wondering if anyone cares about the difference between these two; are there any useful use cases where someone could benefit from knowing when the object was actually destroyed?
-- Jeff Squyres [email protected] For corporate legal information go to: http://www.cisco.com/web/about/doing_business/legal/cri/
_______________________________________________ Mpi3-tools mailing list [email protected] http://lists.mpi-forum.org/mailman/listinfo.cgi/mpi3-tools
participants (1)
-
William Gropp