On 8/1/07, Jeff Squyres <jsquyres_at_[hidden]> 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.
> 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
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.
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