On Thu, Feb 12, 2009 at 10:02 PM, Jeff Squyres <jsquyres_at_[hidden]> 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
Jeff, once again, many thanks for you fast response, and even more
thanks for fixing the issues!
> Jeff Squyres
> Cisco Systems
> devel mailing list
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