FWIW, I'm not really sure I see how the failure for MPI_ARECV to get a buffer (via malloc or whatever mechanism it wants) is substantially different than failing to get a buffer for any incoming message. Indeed, for ARECV, an implementation may well try to use a freelist to allocate a buffer, or fully-lazily allocate a buffer (because it won't know the size until the message is received). Meaning that the allocation will (potentially) occur on the same/similar path as all receive messages. Put that together with the fact that normal receives can also fail to get an eager or unexpected buffer when a new message arrives, for example. Therefore the error handling could well be the same between the ARECV and "regular" receive cases. On Aug 26, 2013, at 11:27 AM, Pavan Balaji <[email protected]> wrote:
Can you clarify a bit more?
Is that a fatal failure at that point? Or is it more like MPI_Alloc_mem failing where I can retry later or just do a regular malloc (in this case, a regular MPI_RECV).
-- Pavan
On 08/26/2013 10:19 AM, David Goodell (dgoodell) wrote:
I'd say that's implementation defined behavior, no different than hitting any other system resource limitation right now.
-Dave
On Aug 26, 2013, at 10:14 AM, Pavan Balaji <[email protected]> wrote:
Jeff,
This should probably be moved to the point-to-point WG, but I'll comment on this thread for now.
Such a proposal was brought up at the very early stage of the MPI-2.1 process (I don't remember by whom). The main concern at that point was what happens when the memory allocation fails. Will the receive fail? What happens to the sent message?
Can you work these details into your slides?
-- Pavan
On 08/26/2013 10:10 AM, Jeff Squyres (jsquyres) wrote:
Dave Goodell and I have a proposal that we've socialized a bit around with other Forum members, and would now like larger Forum feedback. I'll be presenting the attached slides on the concept of an "allocate receive" in Madrid (3:30-4pm on Thursday).
There's no text or ticket yet; this is an idea that we want to get feedback on before working up a full proposal.
_______________________________________________ mpi-forum mailing list [email protected] http://lists.mpi-forum.org/mailman/listinfo.cgi/mpi-forum
-- Pavan Balaji http://www.mcs.anl.gov/~balaji _______________________________________________ mpi-forum mailing list [email protected] http://lists.mpi-forum.org/mailman/listinfo.cgi/mpi-forum
_______________________________________________ mpi-forum mailing list [email protected] http://lists.mpi-forum.org/mailman/listinfo.cgi/mpi-forum
-- Pavan Balaji http://www.mcs.anl.gov/~balaji _______________________________________________ mpi-forum mailing list [email protected] http://lists.mpi-forum.org/mailman/listinfo.cgi/mpi-forum
-- Jeff Squyres [email protected] For corporate legal information go to: http://www.cisco.com/web/about/doing_business/legal/cri/