Nobody stepped up, so I fixed this in r26257
On Apr 9, 2012, at 9:21 AM, Ralph Castain wrote:
> FWIW: this isn't a bug in orte_dpm, but in the MPI binding for comm_join. The problem is that both sides in the comm_join are setting "send_first" to true - i.e., both sides are trying to be the first to send on the handshake. We got away with this before because of a bug in orte_dpm that made the value of send_first irrelevant, but that has now been fixed.
> So someone needs to figure out how to properly set "send_first" in comm_join so that the two sides agree on who does what first. Looking at the code, it isn't obvious to me how one would do so as I don't see any rank info passed into the function.
> On Apr 9, 2012, at 8:31 AM, Josh Hursey wrote:
>> This is totally not related to the bug report, but a neat trick in Trac.
>> My question was "what were the commits between r26240 and 26249"?
>> In the search box type:
>> Or use the direct url:
>> -- Josh
>> On Mon, Apr 9, 2012 at 9:17 AM, TERRY DONTJE <terry.dontje_at_[hidden]> wrote:
>>> After looking at Oracles MTT results there seem to be a (some??) regressions
>>> between r26240 and 26249 detected by the ibm and intel tests suites. An
>>> example of this is the failures in the comm_join, final and loop_spawn tests
>>> of the ibm test suite as seen in
>>> Note, I've seen similar errors detected by IU runs too.
>>> I'll look further into this but I thought I would post this just in case
>>> someone else has seen this.
>>> Terry D. Dontje | Principal Software Engineer
>>> Developer Tools Engineering | +1.781.442.2631
>>> Oracle - Performance Technologies
>>> 95 Network Drive, Burlington, MA 01803
>>> Email terry.dontje_at_[hidden]
>>> devel mailing list
>> Joshua Hursey
>> Postdoctoral Research Associate
>> Oak Ridge National Laboratory
>> devel mailing list