On Sun, 9 Nov 2008, Benjamin Kirk wrote: > The approach taken here is to always call 'Parallel::send()' and > 'Parallel::receive()', where the blocking/nonblocking distinction is > inferred from the absence (or presence) of a request object.
I told you that I now agreed that overloading the function parameters was a better way to express blocking/nonblocking; I didn't expect you to spend your weekend implementing it! ;-) I wonder whether it would be better to have a special singleton Request option (called "blocking_request" or some such) that had to be passed in to specify a non-blocking request. That would cut our number of function signatures in half, would allow blocking vs. non-blocking to be chosen at runtime, and it would make it clear to any newbie writing a blocking I/O call that they could be writing a nonblocking call instead. On the other hand, it would require a slightly complicated implementation, it would require a runtime "if" that would be unnecessary 99% of the time, and it might be less intuitive to use. The way you've already designed things is great. --- 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
