We've currently got a discrepancy between how Parallel::send_receive behaves on vectors (transmitting size information first, then resizing the vector at the receiving end) and how Parallel::receive (or nonblocking_receive) behaves (assuming that the user has already resized the receiving vector to be large enough, and crashing if it isn't).
I think the right thing to do is for the default methods to be nice (resizing the receiving vector) and for alternative methods to be efficient (assuming the receiving processor has sufficient size already, and thus not wasting time on sending a separate int first). There are times when the receiving code won't know how much data is incoming before the sending code tells it, and times when it will, and I'd like a terse method call for each case. My questions are: Does anyone have any thoughts/disagreement? 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(). --- Roy ------------------------------------------------------------------------- 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 [email protected] https://lists.sourceforge.net/lists/listinfo/libmesh-devel
