This web mail archive is frozen.
This page is part of a frozen web archive of this mailing list.
You can still navigate around this archive, but know that no new mails
have been added to it since July of 2016.
Click here to be taken to the new web archives of this list; it includes all the mails that are in this frozen archive plus all new mails that have been sent to the list since it was migrated to the new archives.
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