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?


----- Original Message -----
From: Roy Stogner <roystgnr@ices.utexas.edu>
To: Kirk, Benjamin (JSC-EG)
Cc: libmesh-devel@lists.sourceforge.net <libmesh-devel@lists.sourceforge.net>
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.