Thanks for your reviews. Will you apply this patch as it is or should I
include it again in my upcoming rework of the other patches?
Adrian
On Wed, Dec 04, 2013 at 03:58:49PM +, Jeff Squyres (jsquyres) wrote:
> +1 on this patch.
>
>
> On Nov 25, 2013, at 9:59 AM, Adrian Reb
Let's see what Josh says (he said he'd review the patches today). I'm guessing
he'll be ok with this one, but let's see.
On Dec 6, 2013, at 6:25 AM, Adrian Reber wrote:
> Thanks for your reviews. Will you apply this patch as it is or should I
> include it again in my upcoming rework of the ot
This patch looks good to me. Let me look at some of the others.
On Fri, Dec 6, 2013 at 7:14 AM, Jeff Squyres (jsquyres)
wrote:
> Let's see what Josh says (he said he'd review the patches today). I'm
> guessing he'll be ok with this one, but let's see.
>
>
> On Dec 6, 2013, at 6:25 AM, Adrian Re
Sounds good; thanks Josh. I'll go apply this to the trunk.
On Dec 6, 2013, at 9:21 AM, Josh Hursey wrote:
> This patch looks good to me. Let me look at some of the others.
>
>
> On Fri, Dec 6, 2013 at 7:14 AM, Jeff Squyres (jsquyres)
> wrote:
> Let's see what Josh says (he said he'd review
Since the blocking semantics are important for correctness of the prior
code, I would not just replace send_buffer with send_buffer_nb. This makes
the semantics incorrect, and will make things confusing later when you try
to sort out prior calls to send_buffer_nb with those that you replaced.
As a
Per my other email, I would suggest #ifdef comments instead of nonblocking
replacements for the blocking calls. After that modification, I think this
patch is fine. As was mentioned previously, we will need to go back (after
things compile) and figure out a new model for this behavior.
For the exi
Good points.
You know, this checkpoint stuff is all on the agenda to discuss next week at
the OMPI dev meeting in Chicago. Ralph correctly points out that since the
fundamental design of ORTE has changed (which caused all this FT bit rot), a
bunch of the original FT design isn't right (or nece
Did the mca_base_component_distill_checkpoint_ready paramter go away? Its
intention was to allow a user to have a build with C/R compiled in and then
choose at runtime if they want to restrict their component section to just
C/R enabled components or not. I have reservations about that part of the
That's a great idea Jeff. I did not know it had made it on the agenda for
that meeting. I would like to attend, and my Friday morning is pretty open
at the moment. With timezones, would a doodle poll be useful here or do you
think we can sort it out via email?
Thanks.
Josh
On Fri, Dec 6, 2013 a
To those who care about the openib BTL...
SHORT VERSION
-
Do you really want to call ibv_fork_init() in the openib BTL by default?
MORE DETAIL
---
Rolf V. pointed out to me yesterday that we're calling ibv_fork_init() in the
openib BTL. He asked if we did the same in the u
Hi folks
Per the OMPI developer's telecon this week, I've prepared a temporary branch
that contains a preliminary port of the OSHMEM work to the 1.7.4 release branch:
https://svn.open-mpi.org/svn/ompi/tmp-public/1.7-oshmem
Please take the time to smoke test it so we can merge it into the offici
I saw that the meeting would be available via webex and was planning to
join. So yes, I will be there and it would be great to hear what
is discussed about the FT design and what needs to be changed.
Adrian
On Fri, Dec 06, 2013 at 02:36:09PM +, Jeff Squyres (jsquyres) wrote:
>
Great!
Would any particular time be good for you? Josh won't be there in person, but
will be in the same timezone as the meeting (US Central). I'm assuming you'd
want a start time like 9am, or 10am US Central at the latest.
On Dec 6, 2013, at 4:12 PM, Adrian Reber wrote:
> I saw that the m
13 matches
Mail list logo
