[Mpi-forum] [EXTERNAL] Re: MPI "Allocate receive" proposal

[Dries Kimpe]

* Barrett, Brian W <bwbarre at sandia.gov> [2013-08-26 16:35:57]:

> On 8/26/13 10:31 AM, "Dries Kimpe" <dkimpe at mcs.anl.gov> wrote:

> >* Barrett, Brian W <bwbarre at sandia.gov> [2013-08-26 16:06:00]:

> >[...]

> >> That being said, I don't think resource exhaustion corner cases are a
> >>deal
> >> breaker for me.  I think some implementation-dependent phrasing might be
> >> acceptable.  It might be useful to define the message
> >> transmission/matching semantics for these corner cases.  For example, if
> >> MPI_Arecv returns an error because of resource exhaustion, is the
> >>message
> >> lost (my preference) or left in the receive queue?  If the message is
> >> lost, what happens to the sender if the send was a synchronous send?

> >I think allowing the message to be 'lost' should be last resort and not
> >taken lightly, since as far as I know, a message cannot be lost using the
> >existing MPI functions (ignoring fault tolerance/resilience here) and, as
> >you pointout in your example, might cause many complexities at other
> >places.

> Sure they can.  The standard is totally silent on what happens when
> MPI_RECV returns an error.  You're firmly in the realm of undefined
> behavior.

Yes, but you were talking about *defining* semantics which include
dropping a message.

  Dries
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/x-pkcs7-signature
Size: 2257 bytes
Desc: not available
URL: <http://lists.mpi-forum.org/pipermail/mpi-forum/attachments/20130826/340197fb/attachment-0001.bin>