Benjamin Kirk wrote: >> 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...
Oh, good point - I don't see any way to make it truly asynchronous without launching a separate thread to wait for the size integer. "lessblocking_receive", then, for the case where the code blocks waiting for the size but doesn't block waiting for the data? "semiblocking_receive"? 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. --- 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
