Re: [Boost-bugs] [Boost C++ Libraries] #2400: Messages corrupted if isend requests are not retained

Subject: Re: [Boost-bugs] [Boost C++ Libraries] #2400: Messages corrupted if isend requests are not retained
From: Boost C++ Libraries (noreply_at_[hidden])
Date: 2009-08-07 17:01:34


#2400: Messages corrupted if isend requests are not retained
---------------------------------+------------------------------------------
  Reporter: dwchiang@… | Owner: troyer
      Type: Feature Requests | Status: closed
 Milestone: Boost 1.37.0 | Component: mpi
   Version: Boost 1.36.0 | Severity: Problem
Resolution: invalid | Keywords:
---------------------------------+------------------------------------------

Comment(by troyer):

 No, the basic issue is that: you *have to* call wait on the request to
 finish the irecv or isend operation and cannot just discard the object. If
 you do not call wait, the code never checks for completion. There are a
 few solutions, that are sub-optimal:

 1.) keep the buffer alive as you propose, but that will lead to a memory
 leak since the request obejct is the only one who knows about the buffer.
 If you discard the request there will be a leak since nobody ever checks
 for completion.

 2.) have the destructor call wait - but then the code might just hang or
 deadlock in the destructor, which would be very hard to debug.

 3.) have the destructor cancel the request, but then again this leads to
 unexpected behavior, if one discards the request: this automatically
 cancels the send!

 The best option as I can see is to:

 4.) assert on the precondition to the destructor, namely that the request
 has to be finished. Note that we cannot throw an exception in a destructor
 have to abort.

 I don't like option 4 either but it seems the safest and will at least
 tell you that you forgot to wait for completion.

-- 
Ticket URL: <https://svn.boost.org/trac/boost/ticket/2400#comment:7>
Boost C++ Libraries <http://www.boost.org/>
Boost provides free peer-reviewed portable C++ source libraries.

This archive was generated by hypermail 2.1.7 : 2017-02-16 18:50:01 UTC