A opal_pmix.fence seems like a perfect replacement.
George.
On Fri, Dec 19, 2014 at 10:26 AM, Adrian Reber <adr...@lisas.de> wrote:
> Again I am trying to get the FT code working. This time I am unsure how
> to resolve the code changes from this commit:
>
> commit aec5cd08bd8c33677276612b899b48618d271efa
> Author: Ralph Castain <r...@open-mpi.org>
> Date: Thu Aug 21 18:56:47 2014 +0000
>
> Per the PMIx RFC:
>
>
> This includes changes like this:
>
>
> @@ -172,17 +164,7 @@ static int rte_init(void)
> * in the job won't be executing this step, so we would hang
> */
> if (ORTE_PROC_IS_NON_MPI && !orte_do_not_barrier) {
> - orte_grpcomm_collective_t coll;
> - OBJ_CONSTRUCT(&coll, orte_grpcomm_collective_t);
> - coll.id = orte_process_info.peer_modex;
> - coll.active = true;
> - if (ORTE_SUCCESS != (ret = orte_grpcomm.modex(&coll))) {
> - ORTE_ERROR_LOG(ret);
> - error = "orte modex";
> - goto error;
> - }
> - ORTE_WAIT_FOR_COMPLETION(coll.active);
> - OBJ_DESTRUCT(&coll);
> + opal_pmix.fence(NULL, 0);
> }
>
>
> In the FT code in orte/mca/ess/env/ess_env_module.c there is similar code:
>
> OBJ_CONSTRUCT(&coll, orte_grpcomm_collective_t);
> coll.id = orte_process_info.snapc_init_barrier;
>
> ...
>
> if (ORTE_SUCCESS != (ret = orte_grpcomm.barrier(&coll))) {
>
> ...
>
> coll.active = true;
> ORTE_WAIT_FOR_COMPLETION(coll.active);
>
>
> How can this be expressed with the new code?
>
>
> Adrian
> _______________________________________________
> devel mailing list
> de...@open-mpi.org
> Subscription: http://www.open-mpi.org/mailman/listinfo.cgi/devel
> Link to this post:
> http://www.open-mpi.org/community/lists/devel/2014/12/16688.php
>
