[Mpi3-ft] ULFM Slides for Madrid

[Jim Dinan]

Hi Wesley,

Overall, this is going in a great direction.  Thanks for all of the effort
you and others have been putting into the presentation.

Slide 4: "Only requirement is that failure are eventually reported to all
processes which communicate with the failed process."  I am wondering if
this statement, to be precise, applies only to point-to-point
communication?  Is it possible for me to never find out about a failure of
another process with whom I make collective calls?

Slide 5: I haven't heard the term "algorithm completion" before.  Would it
be better to call this something like fault tolerant consensus?

Slide 11: You should point out that we have no way to free a communicator,
if it is not valid at all correct processes.  Processes that noticed the
failure wouldn't be able to call revoke, since they don't have a valid
handle to the communicator.

Slide 12: Should you clean up the communicator somehow, if the creation
failed?  Do you revoke or free it?  Is this semantic defined -- seems like
the same issue as on slide 11?

 ~Jim.


On Fri, Aug 16, 2013 at 1:17 PM, Wesley Bland <wbland at mcs.anl.gov> wrote:

>  I've put together a first draft of some slides that give an overview of
> ULFM for the forum meeting in Madrid for Rich to present. I think I
> captured most of the discussion we had on the last call relating to
> rationale, but if I missed something, feel free to add that to this deck or
> send me edits.
>
> I think the plan of action, as I understand it from Rich and Geoffroy, is
> to iterate on these slides until the next call on Tuesday and then we'll go
> over them as a group to make sure we're all on the same page. Rich, will
> you be able to attend the call this week (Tuesday, 3:00 PM EST)? If not, we
> can adjust it this week to make sure you can be there.
>
> Just to be clear, the goal of this presentation is to provide an overview
> of ULFM for the European crown that can't usually attend the forum
> meetings. This will probably be a review for many of the people who attend
> regularly, but there is some new rationale that we haven't included in the
> past when we've been putting these presentations together. I'd imagine that
> this meeting will have some confusion from the attendees where they might
> remember parts of the previous proposals and mix them, but if we can tell
> them to do a memory wipe ahead of time, that would help.
>
> Let me know what I've missed.
>
> Thanks,
> Wesley
>
> _______________________________________________
> mpi3-ft mailing list
> mpi3-ft at lists.mpi-forum.org
> http://lists.mpi-forum.org/mailman/listinfo.cgi/mpi3-ft
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.mpi-forum.org/pipermail/mpiwg-ft/attachments/20130819/db9ca118/attachment-0001.html>