On 8/6/07, Jeff Squyres <jsquy...@cisco.com> wrote: > On Aug 6, 2007, at 2:42 PM, Lisandro Dalcin wrote: > > 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.
Well, let take two examples: - GROUP_EMPTY is predefined handle. The standard says that some group operations may return ir (for example, Group::Excl). So you get a handle which may (or may not) be GROUP_EMPTY. Then you are going to free the return of Group::Excl(). If it is an empty group, but not equal (in the C == operator sense) to GROUP_EMPTY, then you can safely free it, but if the return is exactly GROUP_EMPTY. what should I do as I user? Should I free it? Well, the standard says nothing about this, and MPI implementations can do what they want. Disccussing this issue with MPICH2 developers, they first decided to generate an error if Group::Free() is called with GROUP_EMPTY, then I updated my code, released a new version of mpi4py, and after all this, they sent me a mail saying they reverted the change (i.e, users can free GROUP_EMPTY) because some extenal code (Intel MPI Benchmark) was failing. And take into account that checking for GROUP_EMPTY is a easy task (just use ==), but even in that case it you do not know if you can safely free the result of a group operation. - Other example is File::Get_view(). This function returns datatype handles. If the returned handle is predefined, you cannot free it (not sure, but i believe the standars explicitely says that), if it is not, you sould free it. But in order to know that, you have to go through datatype decoding. IMHO, all those issues could be corrected in the standard, as follow - Group operations NEVER return GROUP_EMPTY, so the user is in charge to always call Group::Free() on the result. GROUP_EMPTY cannot be freed, and it is just provided by convenience (i.e. you can use Group::Compare() to know if a group has no members). The performance implications of doing this (that is return a true duplicate of the empty group) seems negligible. - File::Get_View() should also never return a predefined datatype, but a duplicate of them (in the Datatype::Dup() sense). Again, I cannot see any performance penalty on this. > 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.). I am currently doing this, but only for issuing a warning if a non-predefined object is 'leaked'. For all local objects, like groups, datatypes, I believe I could go further and enable automatic destruction, but for global objects, like comm, win, files, the deadlock problem is almost impossible to avoid. So for global objects the user is still in charge of doing de destruction. But I am completely fine with this. The only big problem is always to know (in a implementation independed way) if you are able to free a handle. Please, let continue this thread!!! We need to agree in the way things should be done, and surely we should include MPICH2 people in this discussion. This way, we have more chances to correct/clarify things por MPI-2.1 (or even MPI 2.0). Or do you think I should raise all this stuff to mpi-2.1 mailing list? Regarding the archives, the list does not seems to be really active. That's the reason I am always shotting here (and on mpich-maint) with the hope of attract the attention of experienced people like all you (in the end, I was in high-school by the time MPI was borned!!). 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
