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. 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.
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?
-Ben
----- Original Message -----
From: Roy Stogner <[EMAIL PROTECTED]>
To: Kirk, Benjamin (JSC-EG)
Cc: [email protected] <[email protected]>
Sent: Tue Oct 28 17:46:40 2008
Subject: Re: [Libmesh-devel] "recv", "irecv"
On Tue, 28 Oct 2008, Kirk, Benjamin (JSC-EG) wrote:
> I agree too.
> But I vote for
>
> Parallel::dont_be_lazy_and_use_this_blocking_recv();
I can see how blocking sends are nearly always lazy, but receives?
I'd think that usually by the time you know you're going to need some
data, you don't have any more work you can do until you're finished
receiving it. It's the same problem we've got with communication
during linear system assembly.
---
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
