On Thu, Feb 12, 2009 at 10:02 PM, Jeff Squyres <jsquy...@cisco.com> wrote: > On Feb 11, 2009, at 8:24 AM, Lisandro Dalcin wrote: > >> Below a list of stuff that I've got by running mpi4py testsuite. Never >> reported them before just because some of them are not actually >> errors, but anyway, I want to raise the discussion. >> >> - Likely bugs (regarding my interpretation of the MPI standard) >> >> 1) When passing MPI_REQUEST_NULL, MPI_Request_free() DO NOT fail. >> >> 2) When passing MPI_REQUEST_NULL, MPI_Cancel() DO NOT fail. >> >> 3) When passing MPI_REQUEST_NULL, MPI_Request_get_status() DO NOT fail. > > I agree with all of these; I'm not sure why we allowed MPI_REQUEST_NULL. I > double checked LAM/MPI -- it errors in all of these cases. So OMPI now > does, too. > >> 4) When passing MPI_WIN_NULL, MPI_Win_get_errhandler() and >> MPI_Win_set_errhandler() DO NOT fail. > > I was a little more dubious here; the param checking code was specifically > checking for MPI_WIN_NULL and not classifying it as an error. Digging to > find out why we did that, the best that I can come up with is that it is > *not* an error to call MPI_File_set|get_errhandler on MPI_FILE_NULL (to set > behavior for what happens when FILE_OPEN fails); I'm *guessing* that we > simply copied the _File_ code to the _Win_ code and forgot to remove that > extra check. > > I can't find anything in MPI-2.1 that says it is legal to call set|get > errhandler on MPI_WIN_NULL. I checked LAM as well; LAM errors in this case. > So I made this now be an error in OMPI as well. > > Do you need these in the 1.3 series? Or are you ok waiting for 1.4 > (assuming 1.4 takes significantly less time to release than 1.3 :-) ). >
I do not have a strong need to get those fixes in 1.3 series. In mpi4py, I have some compatibility layer in a implementation by implementation (well, actually just MPICH 1/2, Open MPI and LAM) and release by release basis trying to hide those small discrepancies and bugs in the MPI's out there. >> - Unexpected errors classes (at least for me) >> >> 1) When passing MPI_COMM_NULL, MPI_Comm_get_errhandler() fails with >> MPI_ERR_ARG. I would expect MPI_ERR_COMM. > > I don't have a strong feeling on this one; I think you could probably argue > either way. That being said, we haven't paid too close attention to the > error values that we return. Unfortunately, I don't think there's much > standardization between different MPI implementations, unless they share a > common code ancestry. > You are right... However, IMHO, some agreement between Open MPI and MPICH2 would be great, right :) ? In the end, they are the reference/basis for other implementations. >> 2) MPI_Type_free() fails with MPI_ERR_INTERN when passing predefined >> datatypes like MPI_INT or MPI_FLOAT. I would expect MPI_ERR_TYPE. > > Ya, that seems weird. Fixed. > >> - Controversial (I'm even fine with the current behavior) >> >> 1) MPI_Info_get_nthkey(info, n) returns MPI_ERR_INFO_KEY when "n" is >> larger that the number of keys. Perhaps MPI_ERR_ARG would be more >> appropriate? A possible rationale would be that the error is not >> related to the contents of a 'key' string, but an out of range value >> for "n". > > I don't have a particular opinion on this one. > >> That's all. Sorry for being so pedantic :-) and not offering help for >> the patches, but I'm really busy. > > > No worries; this stuff is great. Thanks -- and keep it coming! (we usually > remember to cite people who submit stuff like this; e.g., > https://svn.open-mpi.org/trac/ompi/changeset/20537 and > https://svn.open-mpi.org/trac/ompi/changeset/20538). > Jeff, once again, many thanks for you fast response, and even more thanks for fixing the issues! > -- > Jeff Squyres > Cisco Systems > > _______________________________________________ > devel mailing list > de...@open-mpi.org > http://www.open-mpi.org/mailman/listinfo.cgi/devel > -- 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
