On Aug 6, 2007, at 2:42 PM, Lisandro Dalcin wrote:
having to call XXX.Free() for every
object i get from a call like XXX.Get_something() is really an
unnecesary pain.
Gotcha.
But I don't see why this means that you need to know if an MPI handle
points to an intrinsic object or not...?
Because many predefined, intrinsic objects cannot (or should not be
able to) be freed, acording to the standard.
I understand that. :-) But why would you call XXX.Free() on an
intrinsic object? If you're instantiating an MPI handle, you know
that it's a user-created object and therefore you should MPI free it,
right? If you didn't instantiate it, then it's not a user-defined
object, and therefore you shouldn't MPI free it.
If it's a question of trying to have a generic destructor (pardon me
-- I know next to nothing about python) for your MPI handle classes,
you can have a private member flag in your handle class indicating
whether the underlying MPI handle is intrinsic or not. Have a
special communicator for instantiating the global / intrinsic objects
(e.g., for MPI_INT) that sets this flag for "true"; have all other
constructors set it to "false". In the destructor, you check this
flag and know whether you should call the corresponding MPI free
function (assuming you solve issues surrounding deadlock, etc.).
Yes and no. As the author of the C++ bindings chapter in MPI-2, I
have a pretty good idea why we didn't do this. :-)
Please, do not missunderstand me. C++ bindings are almost perfect for
me. The only thing I object a bit is the open-door for dangling
references. Any way, this is a minor problem. And the C++ bindings are
my source of inspiration for my python wrappers, as they are really
good for me.
Good! That's exactly what they were intended to be. :-)
--
Jeff Squyres
Cisco Systems
