Open MPI logo

Open MPI Development Mailing List Archives

  |   Home   |   Support   |   FAQ   |   all Development mailing list

From: Josh Hursey (jjhursey_at_[hidden])
Date: 2007-10-08 14:11:36


Yeah the non-blocking interface has some fault tolerance benefits as
Brian mentioned. We are not quite far enough along to use it yet. I
think that we might need to extend it a bit, but I haven't looked at
it in enough detail to say how exactly at the moment.

So I would say for the moment leave it out, but leave a note in there
that a non-blocking interface may be added in the future to aid in
network path detection and recovery. Or something like that.

-- Josh

On Oct 8, 2007, at 2:04 PM, Brian Barrett wrote:

> On Oct 8, 2007, at 11:55 AM, 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.
>
> No, no performance advantages.
>
> It was originally intended to allow a BTL to subscribe to modex
> information for a peer, and receive updates when that peer's
> information changed (say, a NIC died mid-run or was restarted mid-
> run). Clearly, we haven't gone down that path at this time.
>
> Brian
> _______________________________________________
> devel mailing list
> devel_at_[hidden]
> http://www.open-mpi.org/mailman/listinfo.cgi/devel