> <[email protected]> wrote: >> On Fri, 22 Oct 2010, John Peterson wrote: >> >> Also, in the code that you mentioned, another thing happens which I think is >> dangerous: That is, you are having a >> >> std::vector<Parallel::Request> node_send_requests; >> >> (and a number of similar vectors), and then, each time you want to send >> something, you do >> >> node_send_requests.push_back(Parallel::request()); >> Parallel::send(...,node_send_requests.back(),...); >> >> While this looks perfectly alright, I noticed that there is a subtle problem >> with this (because I tried to do it the same way in my code and found it not >> working and traced it back), that is: push_back() may possibly have to >> re-allocate memory and copy all elements. In that case, for all previous >> requests, the copy constructor will be called, and then the destructor. But >> the destructor calls MPI_Request_free(), which makes the copy become >> invalid. > > Wow, yeah... this is a serious issue we should resolve ASAP. It's > like having an auto_ptr in an STL container ... a big C++ no-no. > > What do you think Roy? > > We could change the Request class's destructor so that it does not > attempt to manage the lifetime... as I understand it, it's not > necessary to call MPI_Request_free unless you want to actually cancel > an Isend/Irecv operation. So for that we could have an explicit > Request::free() interface. Otherwise I don't think we leak memory > since there is no malloc/new in the first place.
Hmm... That definitely sounds like the right approach to me. But if for some reason it doesn't work we could use a std::list<Parallel::Request> instead. -Ben ------------------------------------------------------------------------------ Achieve Improved Network Security with IP and DNS Reputation. Defend against bad network traffic, including botnets, malware, phishing sites, and compromised hosts - saving your company time, money, and embarrassment. Learn More! http://p.sf.net/sfu/hpdev2dev-nov _______________________________________________ Libmesh-users mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/libmesh-users
