On Tue, 28 Oct 2008, Kirk, Benjamin (JSC-EG) wrote:
Well, you can always post a nonblocking receive before you are ready to
use its contents... There are a couple of places in the code where
processor 0 posts a slew of nonblocking receives, and then all processors
(including 0) post a blocking send.
For serialization? I actually think we're going to want to change
that behavior in the long run. No idea when we'll get around to
changing old code, but eventually I'd like to be able to handle the
case where serialized structures wouldn't even fit on a single
processor - i.e. even if we want to do I/O from processor 0, we'd do
it a chunk at a time.
I guess to be more clear, I have no issue with a nonblocking send
paired with a blocking receive or vice versa, but a blocking send
paired with a blocking receive is much more likely to be a problem.
True.
Do you want to call them all Parallel::send() / Parallel::recv() and use
the presence of a request object to discern blocking vs nonblocking, or
do you think that would just obfuscate things?
Hmmm... I'm leaning toward "obfuscate things", but it's up to you.
---
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
