>>> Does anyone have any idea as to what to name the "non-nice" methods? >>> receive_array? fill? I'm trying to think of something that's >>> descriptive enough but that won't require users to call >>> Parallel::nonblocking_receive_into_pre_sized_vector(). >> >> Is it possible to resize for the user in the case of the nonblocking methods >> without first imposing a blocking communication step? I can't see how that >> would not turn it into a blocking method... > > ... > > Or don't bother writing that case at all? In the places where nonblocking > receives make sense, often any blocking at all would lead to a deadlock - > you'd really want to handle vector sizing manually.
Agreed. If someone is calling the nonblocking methods they pretty much have to have handled the resizing already. Perhaps it is just sufficient to assert the vector is not empty to guard against the truly clueless invocation... BTW, I have decided class methods which return void are wasting an opportunity. When you posed the question I really wanted to transmit the buffer size only in the case when the vector was empty, then a call like this would work fine and be really clear: Parallel::receive (0, vec.clear()); Alas, that would require clear to return a reference, and this is just too cumbersome: Parallel::receive (0, (vec.clear(), vec)); Anyway, I digress. But keep reading... What really bothers me about this approach is the need for the Parallel::presized_send() / Parallel::send() distinction. I'd rather always use Parallel::send() - after all, the sending processor knows its size, and the size is transmitted in the MPI envelope anyway. What about instead using MPI_Probe on the receiving side to get the message size and resizing the buffer when need be? It avoids the unnecessary latency hit of the additional MPI_Send/MPI_Recv associated with the other option. I think we could *always* do that for the blocking methods without much performance hit at all. -Ben .Ben ------------------------------------------------------------------------- This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK & win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100&url=/ _______________________________________________ Libmesh-devel mailing list Libmesh-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/libmesh-devel
