[OMPI devel] Branching the trunk for 1.3, and branch update policy

All: The trunk is now ready to be branched for the 1.3 release. Jeff has volunteered to do the branch in his copious spare time (thanks Jeff!). So, I expect that to happen either this evening or sometime tomorrow. There are numerous tickets to resolve to get 1.3 ready for release. So, for the

Re: [OMPI devel] warn when fork() used with openib btl?

I think this is a good idea, and for the reasons you outline in your Rationale. This definitely bites people from time to time at Big Blue as well, and a gentle warning will certainly help. --brad On Mon, Jun 23, 2008 at 8:42 AM, Jeff Squyres wrote: > Those who care about

Re: [OMPI devel] PML selection logic

It is a good point. What I have prototyped would still handle it - basically, it checks to see if any data has been published and does a modex if so. So if one side does send modex data, the other side will faithfully decode it. I think the bigger issue will be if both sides don't, and they don't

Re: [OMPI devel] PML selection logic

Brian hinted a possible bug in one of his replies. How does this work in the case of dynamic processes? We can envision several scenarios, but lets take a simple: 2 jobs that get connected with connect/accept. One might publish the PML name (simply because the -mca argument was on) and one

Re: [OMPI devel] ob1 and req->req_state

On Montag, 23. Juni 2008, Shipman, Galen M. wrote: > Oh, I see, you are confusing the req_state on the OMPI request with > the req_state on the PML request. > > The ompi request state is for persistent requests, the PML request > state is not and does not use that enum. So, the req_state in

Re: [OMPI devel] PML selection logic

Also sounds good to me. Note that the most difficult part of the forward-looking plan is that we usually can't tell the difference between "something failed to initialize" and "you don't have support for feature X". I like the general philosophy of: running out of the box always works