There are two more interfaces that have changed:
1. orte_rds.query() now takes a job id, whereas in 1.2b1 it didn't
take any arguments. I seem to remember that I call this to kick orted
into action, but I'm not sure of the implications of not calling it.
In any case, I don't have a job id when I call it, so what do I pass
to get the old behavior?
2. orte_pls.terminate_job() now takes a list of attributes in
addition to a job id. What are the attributes for, and what happens
if I pass a NULL here? Do I need to crate an empty attribute list?
On Jan 27, 2007, at 6:51 AM, Ralph Castain wrote:
> On 1/26/07 11:36 PM, "Greg Watson" <gwatson_at_[hidden]> wrote:
>> I have been using this define to implement the orte_stage_gate_init()
>> functionality in PTP using OpenMPI 1.2b1 for some months now. As of
>> 1.2b3 it appears that this define has been removed. New users
>> attempting to build PTP against the latest 1.2b3 build are
>> complaining that they are getting build errors.
>> Please let me know what has replaced this define in 1.2b3, and how we
>> can obtain the same functionality that we had in 1.2b1.
> You need to use ORTE_PROC_MY_HNP - no API change is involved, it is
> just a
> #define. You may need to add #include "orte/mca/ns/ns_types.h" to
> pick it
> You will also find that ORTE_RML_NAME_ANY is likewise gone - you
> need to use
> ORTE_NAME_WILDCARD instead for the same reasons as described below.
> Similarly, ORTE_RML_NAME_SELF has been replaced by ORTE_PROC_MY_NAME.
> We discovered during the testing/debugging of 1.2 that people had
> unintentionally created multiple definitions for several critical
> names in
> the system. Hence, we had an ORTE_RML_NAME_SEED, an ORTE_OOB_SEED, and
> several others. In the event that definition had to change, we
> found the
> code "cracking" all over the place - it was literally impossible to
> So we bit the bullet and cleaned it up. No API changes were
> involved, but we
> did remove duplicative defines (and their associated storage
> Hopefully, people will take the time to lookup and use these system-
> defines instead of re-creating the problem!
>> Also, I would like to know what the policy of changing interfaces is,
>> and when in the release cycle you freeze API changes. It's going to
>> be extremely difficult to release a version of PTP built against
>> OpenMPI if you change interfaces between beta versions.
> In my opinion, that is what "beta" is for - it isn't a "lock-down"
> but rather a time to find your cracks and fix them. That said, we
> change APIs for no reason, but only because we either (a) needed to
> do so to
> add some requested functionality (e.g., the recent request for
> launch capabilities), or (b) found a bug in the system that
> required some
> change or added functionality to fix (e.g., the recent changes in
> the PLS
> behavior and API to support ctrl-c interrupt capabilities).
> I generally try to send emails out alerting people to these changes
> they occur (in fact, I'm pretty certain I sent one out on this issue).
> However, looking back, I find that I send them to the OMPI "core
> list - not the "developers" one. I note that the OMPI layer
> developers tend
> to do the same thing. I'll try to rectify that in the future and
> suggest my
> OMPI compatriots do so too.
> Once an actual release is made, we only make an API change if a
> major bug is
> found and an API change simply must be done to fix it. I don't
> recall such
> an instance, though I think it may have happened once between minor
> numbers in the 1.1 family (not sure).
>> devel mailing list
> devel mailing list