On 8/1/07, Jeff Squyres <jsquy...@cisco.com> wrote: > On Jul 31, 2007, at 6:43 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. > > Many things in MPI are LOCAL (datatypes, groups, predefined > > operations) and in general destroying them for user-space is > > guaranteed by MPI to not conflict with system(MPI)-space and > > communication (i.e. if you create a derived datatype four using it in > > a construction of another derived datatype, you can safely free the > > first). > > > > Well, for all those LOCAL objects, I could implement automatic > > deallocation of handles for Python (for Comm, Win, and File, that is > > not so easy, at freeing them is a collective operation AFAIK, and > > automaticaly freeing them can lead to deadlocks). > > This is a difficult issue -- deadlocks for removing objects that are > collective actions. It's one of the reasons the Forum decided not to > have the C++ bindings automatically free handles when they go out of > scope. An that was a really good and natural decision. > > Sorry for the long mail. In short, many things in MPI are not clearly > > designed for languages other than C and Fortran. Even in C++ > > specification, there are things that are unnaceptable, like the > > open-door to the problem of having dangling references, which could be > > avoided with negligible cost. > > 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. > The standard is meant to be as simple, straightforward, > and cross-language as possible (and look where it is! Imagine if we > had tried to make a real class library -- it would have led to even > more corner cases and imprecision in the official standard). Well, I have to completely agree with you. And as I said before, the corner cases are really a few, compared to all the number of (rather orthogonal) features provided in MPI. And all guess all this is going to be solved with minor clarifications/corrections in MPI-2.1. -- Lisandro Dalcín --------------- Centro Internacional de Métodos Computacionales en Ingeniería (CIMEC) Instituto de Desarrollo Tecnológico para la Industria Química (INTEC) Consejo Nacional de Investigaciones Científicas y Técnicas (CONICET) PTLC - Güemes 3450, (3000) Santa Fe, Argentina Tel/Fax: +54-(0)342-451.1594
