I don't think so (in fact the bookkeeping overhead of the non-blocking
receive is a slight detriment).
Right now modex information is only exchanged during init and during
spawn/dynamics operations (and I do not see that changing at any point
soon). So I think the only use of the non-blocking receive would be to
ask for the information before the exchange has been done. I don't know
if this is helpful to anyone. My guess is not since no one does it.
Tim
Andrew Friedley wrote:
Tim Prins wrote:
Hi,
I am working on implementing the RSL. Part of this is changing the modex
to use the process attribute system in the RSL. I had designed this
system to to include a non-blocking interface.
However, I have looked again and noticed that nobody is using the
non-blocking modex receive. Because of this I am inclined to not have
such an interface in the RSL.
hmm, would using a non-blocking modex recv improve performance in any
way, or have any other useful impacts? If so, I would use it.
Andrew
_______________________________________________
devel mailing list
de...@open-mpi.org
http://www.open-mpi.org/mailman/listinfo.cgi/devel
