On 7/31/07, Jeff Squyres <jsquy...@cisco.com> wrote: > Just curious -- why do you need to know if a handle refers to a > predefined object?
If I understand correctly, new handles shoud be freed in order to do not leak things, to follow good programming practices, and being completelly sure a valgrind run do not report any problem. I am working in the development of MPI for Python, a port of MPI to Python, a high level language with automatic memory management. Said that, in such an environment, having to call XXX.Free() for every object i get from a call like XXX.Get_something() is really an unnecesary pain. 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). My Python wrappers (mpi4py) are inteded to be used in any platform with any MPI implementation. But things are not so easy, as there are many corner cases in the MPI standard. Python es a wonderfull, powerfull language, very friendly to write things. Prove of that is the many bug reports I provided here. By using python, I can run all my unittest script in a single MPI run, thus they have the potential to find interaction problems between all parts of MPI. If any of you, OMPI developers, have some knowledge of Python, I invite you to try mpi4py, as you would be able to write very fast many many tests, not only for things that should work, but also for things that should fail. 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. Anyway, all those issues are minor for me, and the MPI specification is just great. I hope I can find the time to contribute to the MPI-2.1 effort to better define MPI behavior in the corner cases (fortunatelly, there are a really small number of them). Regards, -- 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
