2008-02-28 04:57:57 +03:00
|
|
|
/* -*- C -*-
|
|
|
|
*
|
2010-03-10 03:23:24 +03:00
|
|
|
* Copyright (c) 2004-2010 The Trustees of Indiana University and Indiana
|
2008-02-28 04:57:57 +03:00
|
|
|
* University Research and Technology
|
|
|
|
* Corporation. All rights reserved.
|
2011-06-24 00:38:02 +04:00
|
|
|
* Copyright (c) 2004-2011 The University of Tennessee and The University
|
2008-02-28 04:57:57 +03:00
|
|
|
* of Tennessee Research Foundation. All rights
|
|
|
|
* reserved.
|
|
|
|
* Copyright (c) 2004-2005 High Performance Computing Center Stuttgart,
|
|
|
|
* University of Stuttgart. All rights reserved.
|
|
|
|
* Copyright (c) 2004-2005 The Regents of the University of California.
|
|
|
|
* All rights reserved.
|
|
|
|
* $COPYRIGHT$
|
|
|
|
*
|
|
|
|
* Additional copyrights may follow
|
|
|
|
*
|
|
|
|
* $HEADER$
|
|
|
|
*/
|
|
|
|
/** @file:
|
|
|
|
*
|
|
|
|
*/
|
|
|
|
|
|
|
|
/*
|
|
|
|
* includes
|
|
|
|
*/
|
|
|
|
#include "orte_config.h"
|
|
|
|
|
2009-07-16 22:27:33 +04:00
|
|
|
#ifdef HAVE_STRING_H
|
2009-03-13 05:10:32 +03:00
|
|
|
#include <string.h>
|
|
|
|
#endif
|
2008-06-03 01:46:34 +04:00
|
|
|
#ifdef HAVE_SYS_TIME_H
|
|
|
|
#include <sys/time.h>
|
|
|
|
#endif
|
|
|
|
|
2008-02-28 04:57:57 +03:00
|
|
|
#include "opal/mca/mca.h"
|
|
|
|
#include "opal/mca/base/mca_base_param.h"
|
|
|
|
#include "opal/dss/dss.h"
|
2010-04-23 08:44:41 +04:00
|
|
|
#include "opal/threads/threads.h"
|
2009-12-17 22:39:53 +03:00
|
|
|
|
2009-03-13 05:10:32 +03:00
|
|
|
#include "orte/constants.h"
|
|
|
|
#include "orte/types.h"
|
2008-02-28 04:57:57 +03:00
|
|
|
#include "orte/util/proc_info.h"
|
2010-04-27 19:58:04 +04:00
|
|
|
#include "orte/util/error_strings.h"
|
2008-02-28 04:57:57 +03:00
|
|
|
#include "orte/mca/errmgr/errmgr.h"
|
2011-06-24 00:38:02 +04:00
|
|
|
#include "orte/mca/ess/ess.h"
|
2008-02-28 04:57:57 +03:00
|
|
|
#include "orte/mca/rml/rml.h"
|
2009-02-14 05:26:12 +03:00
|
|
|
#include "orte/mca/rml/rml_types.h"
|
2008-02-28 04:57:57 +03:00
|
|
|
#include "orte/mca/routed/routed.h"
|
2009-07-14 18:34:11 +04:00
|
|
|
#include "orte/mca/ras/base/base.h"
|
2008-02-28 04:57:57 +03:00
|
|
|
#include "orte/util/name_fns.h"
|
|
|
|
#include "orte/runtime/orte_globals.h"
|
2010-07-18 01:03:27 +04:00
|
|
|
#include "orte/runtime/orte_quit.h"
|
2008-02-28 04:57:57 +03:00
|
|
|
|
|
|
|
#include "orte/mca/plm/plm_types.h"
|
|
|
|
#include "orte/mca/plm/plm.h"
|
|
|
|
#include "orte/mca/plm/base/plm_private.h"
|
2008-02-28 22:58:32 +03:00
|
|
|
#include "orte/mca/plm/base/base.h"
|
2008-02-28 04:57:57 +03:00
|
|
|
|
|
|
|
static bool recv_issued=false;
|
2009-07-19 22:07:04 +04:00
|
|
|
static opal_mutex_t lock;
|
2010-04-23 08:44:41 +04:00
|
|
|
static opal_condition_t cond;
|
2009-07-19 22:07:04 +04:00
|
|
|
static opal_list_t recvs;
|
|
|
|
static opal_event_t ready;
|
|
|
|
static int ready_fd[2];
|
|
|
|
static bool processing;
|
|
|
|
|
|
|
|
static void process_msg(int fd, short event, void *data);
|
2008-02-28 04:57:57 +03:00
|
|
|
|
|
|
|
int orte_plm_base_comm_start(void)
|
|
|
|
{
|
|
|
|
int rc;
|
|
|
|
|
|
|
|
if (recv_issued) {
|
|
|
|
return ORTE_SUCCESS;
|
|
|
|
}
|
|
|
|
|
2008-06-09 18:53:58 +04:00
|
|
|
OPAL_OUTPUT_VERBOSE((5, orte_plm_globals.output,
|
2008-02-28 04:57:57 +03:00
|
|
|
"%s plm:base:receive start comm",
|
2009-03-06 00:50:47 +03:00
|
|
|
ORTE_NAME_PRINT(ORTE_PROC_MY_NAME)));
|
2008-02-28 04:57:57 +03:00
|
|
|
|
2009-07-19 22:07:04 +04:00
|
|
|
processing = false;
|
|
|
|
OBJ_CONSTRUCT(&lock, opal_mutex_t);
|
2010-04-23 08:44:41 +04:00
|
|
|
OBJ_CONSTRUCT(&cond, opal_condition_t);
|
2009-07-19 22:07:04 +04:00
|
|
|
OBJ_CONSTRUCT(&recvs, opal_list_t);
|
2009-07-22 11:39:52 +04:00
|
|
|
#ifndef __WINDOWS__
|
2009-07-19 22:07:04 +04:00
|
|
|
pipe(ready_fd);
|
2009-07-22 11:39:52 +04:00
|
|
|
#else
|
2010-10-26 18:53:50 +04:00
|
|
|
if (create_socketpair(AF_UNIX, SOCK_STREAM, 0, ready_fd) == -1) {
|
2009-07-22 11:39:52 +04:00
|
|
|
return ORTE_ERROR;
|
|
|
|
}
|
|
|
|
#endif
|
|
|
|
|
2010-10-28 19:22:46 +04:00
|
|
|
memset(&ready, 0, sizeof(opal_event_t));
|
|
|
|
opal_event_set(opal_event_base, &ready, ready_fd[0], OPAL_EV_READ, process_msg, NULL);
|
|
|
|
opal_event_add(&ready, 0);
|
2009-07-19 22:07:04 +04:00
|
|
|
|
2008-02-28 04:57:57 +03:00
|
|
|
if (ORTE_SUCCESS != (rc = orte_rml.recv_buffer_nb(ORTE_NAME_WILDCARD,
|
|
|
|
ORTE_RML_TAG_PLM,
|
2008-02-28 22:58:32 +03:00
|
|
|
ORTE_RML_NON_PERSISTENT,
|
2008-02-28 04:57:57 +03:00
|
|
|
orte_plm_base_recv,
|
|
|
|
NULL))) {
|
|
|
|
ORTE_ERROR_LOG(rc);
|
|
|
|
}
|
|
|
|
recv_issued = true;
|
|
|
|
|
|
|
|
return rc;
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
|
|
int orte_plm_base_comm_stop(void)
|
|
|
|
{
|
|
|
|
if (!recv_issued) {
|
|
|
|
return ORTE_SUCCESS;
|
|
|
|
}
|
|
|
|
|
2009-07-19 22:07:04 +04:00
|
|
|
OBJ_DESTRUCT(&recvs);
|
2010-10-28 19:22:46 +04:00
|
|
|
opal_event_del(&ready);
|
2009-07-22 11:39:52 +04:00
|
|
|
#ifndef __WINDOWS__
|
2009-07-19 22:07:04 +04:00
|
|
|
close(ready_fd[0]);
|
2009-07-22 11:39:52 +04:00
|
|
|
#else
|
|
|
|
closesocket(ready_fd[0]);
|
|
|
|
#endif
|
2009-07-19 22:07:04 +04:00
|
|
|
processing = false;
|
|
|
|
OBJ_DESTRUCT(&lock);
|
|
|
|
|
2008-06-09 18:53:58 +04:00
|
|
|
OPAL_OUTPUT_VERBOSE((5, orte_plm_globals.output,
|
2008-02-28 04:57:57 +03:00
|
|
|
"%s plm:base:receive stop comm",
|
2009-03-06 00:50:47 +03:00
|
|
|
ORTE_NAME_PRINT(ORTE_PROC_MY_NAME)));
|
2008-02-28 04:57:57 +03:00
|
|
|
|
2008-04-14 22:26:08 +04:00
|
|
|
orte_rml.recv_cancel(ORTE_NAME_WILDCARD, ORTE_RML_TAG_PLM);
|
2008-02-28 04:57:57 +03:00
|
|
|
recv_issued = false;
|
|
|
|
|
2008-04-14 22:26:08 +04:00
|
|
|
return ORTE_SUCCESS;
|
2008-02-28 04:57:57 +03:00
|
|
|
}
|
|
|
|
|
|
|
|
|
2008-02-28 22:58:32 +03:00
|
|
|
/* process incoming messages in order of receipt */
|
2009-12-17 22:39:53 +03:00
|
|
|
static void process_msg(int fd, short event, void *data)
|
2008-02-28 04:57:57 +03:00
|
|
|
{
|
2009-07-19 22:07:04 +04:00
|
|
|
orte_msg_packet_t *msgpkt;
|
2008-02-28 04:57:57 +03:00
|
|
|
orte_plm_cmd_flag_t command;
|
|
|
|
orte_std_cntr_t count;
|
|
|
|
orte_jobid_t job;
|
2008-03-27 00:18:16 +03:00
|
|
|
orte_job_t *jdata, *parent;
|
2008-03-25 17:57:34 +03:00
|
|
|
opal_buffer_t answer;
|
2008-02-28 04:57:57 +03:00
|
|
|
orte_vpid_t vpid;
|
2011-08-27 02:16:14 +04:00
|
|
|
#if ORTE_ENABLE_EPOCH
|
2011-06-24 00:38:02 +04:00
|
|
|
orte_epoch_t epoch;
|
2011-08-27 02:16:14 +04:00
|
|
|
#endif
|
2009-06-27 00:54:58 +04:00
|
|
|
orte_proc_t *proc;
|
2008-02-28 04:57:57 +03:00
|
|
|
orte_proc_state_t state;
|
|
|
|
orte_exit_code_t exit_code;
|
2009-07-19 22:07:04 +04:00
|
|
|
int rc=ORTE_SUCCESS, ret;
|
2009-06-27 00:54:58 +04:00
|
|
|
orte_app_context_t *app, *child_app;
|
2009-07-19 22:07:04 +04:00
|
|
|
opal_list_item_t *item;
|
|
|
|
int dump[128];
|
2010-04-23 08:44:41 +04:00
|
|
|
orte_process_name_t name;
|
|
|
|
pid_t pid;
|
|
|
|
bool running;
|
2009-07-19 22:07:04 +04:00
|
|
|
|
2010-04-23 08:44:41 +04:00
|
|
|
OPAL_ACQUIRE_THREAD(&lock, &cond, &processing);
|
2008-02-28 22:58:32 +03:00
|
|
|
|
2009-09-09 09:31:06 +04:00
|
|
|
OPAL_OUTPUT_VERBOSE((5, orte_plm_globals.output,
|
|
|
|
"%s plm:base:receive processing msg",
|
|
|
|
ORTE_NAME_PRINT(ORTE_PROC_MY_NAME)));
|
|
|
|
|
2009-07-19 22:07:04 +04:00
|
|
|
/* clear the file descriptor to stop the event from refiring */
|
2009-07-22 11:39:52 +04:00
|
|
|
#ifndef __WINDOWS__
|
2009-07-19 22:07:04 +04:00
|
|
|
read(fd, &dump, sizeof(dump));
|
2009-07-22 11:39:52 +04:00
|
|
|
#else
|
|
|
|
recv(fd, (char *) &dump, sizeof(dump), 0);
|
|
|
|
#endif
|
2008-02-28 22:58:32 +03:00
|
|
|
|
2010-04-23 08:44:41 +04:00
|
|
|
/* reset the event for the next message */
|
2010-10-28 19:22:46 +04:00
|
|
|
opal_event_add(&ready, 0);
|
2010-04-23 08:44:41 +04:00
|
|
|
|
2009-07-19 22:07:04 +04:00
|
|
|
while (NULL != (item = opal_list_remove_first(&recvs))) {
|
|
|
|
msgpkt = (orte_msg_packet_t*)item;
|
|
|
|
|
|
|
|
/* setup a default response */
|
|
|
|
OBJ_CONSTRUCT(&answer, opal_buffer_t);
|
|
|
|
job = ORTE_JOBID_INVALID;
|
|
|
|
|
|
|
|
count = 1;
|
|
|
|
if (ORTE_SUCCESS != (rc = opal_dss.unpack(msgpkt->buffer, &command, &count, ORTE_PLM_CMD))) {
|
|
|
|
ORTE_ERROR_LOG(rc);
|
|
|
|
goto CLEANUP;
|
|
|
|
}
|
|
|
|
|
|
|
|
switch (command) {
|
2010-07-01 23:37:53 +04:00
|
|
|
case ORTE_PLM_LAUNCH_JOB_CMD:
|
|
|
|
OPAL_OUTPUT_VERBOSE((5, orte_plm_globals.output,
|
|
|
|
"%s plm:base:receive job launch command",
|
|
|
|
ORTE_NAME_PRINT(ORTE_PROC_MY_NAME)));
|
|
|
|
|
|
|
|
/* unpack the job object */
|
|
|
|
count = 1;
|
|
|
|
if (ORTE_SUCCESS != (rc = opal_dss.unpack(msgpkt->buffer, &jdata, &count, ORTE_JOB))) {
|
|
|
|
ORTE_ERROR_LOG(rc);
|
|
|
|
goto ANSWER_LAUNCH;
|
|
|
|
}
|
2010-08-28 18:03:17 +04:00
|
|
|
|
|
|
|
/* flag that this is a dynamic spawn */
|
|
|
|
jdata->dyn_spawn_active = true;
|
|
|
|
|
Although we never really thought about it, we made an unconscious assumption in the mapper system - we assumed that the daemons would be placed on nodes in the order that the nodes appear in the allocation. In other words, we assumed that the launch environment would map processes in node order.
Turns out, this isn't necessarily true. The Cray, for example, launches processes in a toroidal pattern, thus causing the daemons to wind up somewhere other than what we thought. Other environments (e.g., slurm) are also capable of such behavior, depending upon the default mapping algorithm they are told to use.
Resolve this problem by making the daemon-to-node assignment in the affected environments when the daemon calls back and tells us what node it is on. Order the nodes in the mapping list so they are in daemon-vpid order as opposed to the order in which they show in the allocation. For environments that don't exhibit this mapping behavior (e.g., rsh), this won't have any impact.
Also, clean up the vm launch procedure a little bit so it more closely aligns with the state machine implementation that is coming, and remove some lingering "slave" code.
This commit was SVN r25551.
2011-11-30 23:58:24 +04:00
|
|
|
/* get the parent's job object */
|
|
|
|
if (NULL == (parent = orte_get_job_data_object(msgpkt->sender.jobid))) {
|
|
|
|
ORTE_ERROR_LOG(ORTE_ERR_NOT_FOUND);
|
|
|
|
goto ANSWER_LAUNCH;
|
|
|
|
}
|
2009-07-19 22:07:04 +04:00
|
|
|
|
Although we never really thought about it, we made an unconscious assumption in the mapper system - we assumed that the daemons would be placed on nodes in the order that the nodes appear in the allocation. In other words, we assumed that the launch environment would map processes in node order.
Turns out, this isn't necessarily true. The Cray, for example, launches processes in a toroidal pattern, thus causing the daemons to wind up somewhere other than what we thought. Other environments (e.g., slurm) are also capable of such behavior, depending upon the default mapping algorithm they are told to use.
Resolve this problem by making the daemon-to-node assignment in the affected environments when the daemon calls back and tells us what node it is on. Order the nodes in the mapping list so they are in daemon-vpid order as opposed to the order in which they show in the allocation. For environments that don't exhibit this mapping behavior (e.g., rsh), this won't have any impact.
Also, clean up the vm launch procedure a little bit so it more closely aligns with the state machine implementation that is coming, and remove some lingering "slave" code.
This commit was SVN r25551.
2011-11-30 23:58:24 +04:00
|
|
|
/* if the prefix was set in the parent's job, we need to transfer
|
|
|
|
* that prefix to the child's app_context so any further launch of
|
|
|
|
* orteds can find the correct binary. There always has to be at
|
|
|
|
* least one app_context in both parent and child, so we don't
|
|
|
|
* need to check that here. However, be sure not to overwrite
|
|
|
|
* the prefix if the user already provided it!
|
|
|
|
*/
|
|
|
|
app = (orte_app_context_t*)opal_pointer_array_get_item(parent->apps, 0);
|
|
|
|
child_app = (orte_app_context_t*)opal_pointer_array_get_item(jdata->apps, 0);
|
|
|
|
if (NULL != app->prefix_dir &&
|
|
|
|
NULL == child_app->prefix_dir) {
|
|
|
|
child_app->prefix_dir = strdup(app->prefix_dir);
|
|
|
|
}
|
2009-07-19 22:07:04 +04:00
|
|
|
|
Although we never really thought about it, we made an unconscious assumption in the mapper system - we assumed that the daemons would be placed on nodes in the order that the nodes appear in the allocation. In other words, we assumed that the launch environment would map processes in node order.
Turns out, this isn't necessarily true. The Cray, for example, launches processes in a toroidal pattern, thus causing the daemons to wind up somewhere other than what we thought. Other environments (e.g., slurm) are also capable of such behavior, depending upon the default mapping algorithm they are told to use.
Resolve this problem by making the daemon-to-node assignment in the affected environments when the daemon calls back and tells us what node it is on. Order the nodes in the mapping list so they are in daemon-vpid order as opposed to the order in which they show in the allocation. For environments that don't exhibit this mapping behavior (e.g., rsh), this won't have any impact.
Also, clean up the vm launch procedure a little bit so it more closely aligns with the state machine implementation that is coming, and remove some lingering "slave" code.
This commit was SVN r25551.
2011-11-30 23:58:24 +04:00
|
|
|
OPAL_OUTPUT_VERBOSE((5, orte_plm_globals.output,
|
|
|
|
"%s plm:base:receive adding hosts",
|
|
|
|
ORTE_NAME_PRINT(ORTE_PROC_MY_NAME)));
|
2010-04-23 08:44:41 +04:00
|
|
|
|
Although we never really thought about it, we made an unconscious assumption in the mapper system - we assumed that the daemons would be placed on nodes in the order that the nodes appear in the allocation. In other words, we assumed that the launch environment would map processes in node order.
Turns out, this isn't necessarily true. The Cray, for example, launches processes in a toroidal pattern, thus causing the daemons to wind up somewhere other than what we thought. Other environments (e.g., slurm) are also capable of such behavior, depending upon the default mapping algorithm they are told to use.
Resolve this problem by making the daemon-to-node assignment in the affected environments when the daemon calls back and tells us what node it is on. Order the nodes in the mapping list so they are in daemon-vpid order as opposed to the order in which they show in the allocation. For environments that don't exhibit this mapping behavior (e.g., rsh), this won't have any impact.
Also, clean up the vm launch procedure a little bit so it more closely aligns with the state machine implementation that is coming, and remove some lingering "slave" code.
This commit was SVN r25551.
2011-11-30 23:58:24 +04:00
|
|
|
/* process any add-hostfile and add-host options that were provided */
|
|
|
|
if (ORTE_SUCCESS != (rc = orte_ras_base_add_hosts(jdata))) {
|
|
|
|
ORTE_ERROR_LOG(rc);
|
|
|
|
goto ANSWER_LAUNCH;
|
|
|
|
}
|
2009-07-19 22:07:04 +04:00
|
|
|
|
Although we never really thought about it, we made an unconscious assumption in the mapper system - we assumed that the daemons would be placed on nodes in the order that the nodes appear in the allocation. In other words, we assumed that the launch environment would map processes in node order.
Turns out, this isn't necessarily true. The Cray, for example, launches processes in a toroidal pattern, thus causing the daemons to wind up somewhere other than what we thought. Other environments (e.g., slurm) are also capable of such behavior, depending upon the default mapping algorithm they are told to use.
Resolve this problem by making the daemon-to-node assignment in the affected environments when the daemon calls back and tells us what node it is on. Order the nodes in the mapping list so they are in daemon-vpid order as opposed to the order in which they show in the allocation. For environments that don't exhibit this mapping behavior (e.g., rsh), this won't have any impact.
Also, clean up the vm launch procedure a little bit so it more closely aligns with the state machine implementation that is coming, and remove some lingering "slave" code.
This commit was SVN r25551.
2011-11-30 23:58:24 +04:00
|
|
|
if( NULL == parent->bookmark ) {
|
|
|
|
/* find the sender's node in the job map */
|
|
|
|
if (NULL != (proc = (orte_proc_t*)opal_pointer_array_get_item(parent->procs, msgpkt->sender.vpid))) {
|
|
|
|
/* set the bookmark so the child starts from that place - this means
|
|
|
|
* that the first child process could be co-located with the proc
|
|
|
|
* that called comm_spawn, assuming slots remain on that node. Otherwise,
|
|
|
|
* the procs will start on the next available node
|
|
|
|
*/
|
|
|
|
jdata->bookmark = proc->node;
|
2010-07-01 23:37:53 +04:00
|
|
|
}
|
Although we never really thought about it, we made an unconscious assumption in the mapper system - we assumed that the daemons would be placed on nodes in the order that the nodes appear in the allocation. In other words, we assumed that the launch environment would map processes in node order.
Turns out, this isn't necessarily true. The Cray, for example, launches processes in a toroidal pattern, thus causing the daemons to wind up somewhere other than what we thought. Other environments (e.g., slurm) are also capable of such behavior, depending upon the default mapping algorithm they are told to use.
Resolve this problem by making the daemon-to-node assignment in the affected environments when the daemon calls back and tells us what node it is on. Order the nodes in the mapping list so they are in daemon-vpid order as opposed to the order in which they show in the allocation. For environments that don't exhibit this mapping behavior (e.g., rsh), this won't have any impact.
Also, clean up the vm launch procedure a little bit so it more closely aligns with the state machine implementation that is coming, and remove some lingering "slave" code.
This commit was SVN r25551.
2011-11-30 23:58:24 +04:00
|
|
|
} else {
|
|
|
|
jdata->bookmark = parent->bookmark;
|
|
|
|
}
|
2009-07-19 22:07:04 +04:00
|
|
|
|
Although we never really thought about it, we made an unconscious assumption in the mapper system - we assumed that the daemons would be placed on nodes in the order that the nodes appear in the allocation. In other words, we assumed that the launch environment would map processes in node order.
Turns out, this isn't necessarily true. The Cray, for example, launches processes in a toroidal pattern, thus causing the daemons to wind up somewhere other than what we thought. Other environments (e.g., slurm) are also capable of such behavior, depending upon the default mapping algorithm they are told to use.
Resolve this problem by making the daemon-to-node assignment in the affected environments when the daemon calls back and tells us what node it is on. Order the nodes in the mapping list so they are in daemon-vpid order as opposed to the order in which they show in the allocation. For environments that don't exhibit this mapping behavior (e.g., rsh), this won't have any impact.
Also, clean up the vm launch procedure a little bit so it more closely aligns with the state machine implementation that is coming, and remove some lingering "slave" code.
This commit was SVN r25551.
2011-11-30 23:58:24 +04:00
|
|
|
/* launch it */
|
|
|
|
OPAL_OUTPUT_VERBOSE((5, orte_plm_globals.output,
|
|
|
|
"%s plm:base:receive calling spawn",
|
|
|
|
ORTE_NAME_PRINT(ORTE_PROC_MY_NAME)));
|
|
|
|
OPAL_RELEASE_THREAD(&lock, &cond, &processing);
|
|
|
|
if (ORTE_SUCCESS != (rc = orte_plm.spawn(jdata))) {
|
|
|
|
ORTE_ERROR_LOG(rc);
|
2011-12-15 22:04:48 +04:00
|
|
|
OPAL_ACQUIRE_THREAD(&lock, &cond, &processing);
|
|
|
|
goto DEPART;
|
Although we never really thought about it, we made an unconscious assumption in the mapper system - we assumed that the daemons would be placed on nodes in the order that the nodes appear in the allocation. In other words, we assumed that the launch environment would map processes in node order.
Turns out, this isn't necessarily true. The Cray, for example, launches processes in a toroidal pattern, thus causing the daemons to wind up somewhere other than what we thought. Other environments (e.g., slurm) are also capable of such behavior, depending upon the default mapping algorithm they are told to use.
Resolve this problem by making the daemon-to-node assignment in the affected environments when the daemon calls back and tells us what node it is on. Order the nodes in the mapping list so they are in daemon-vpid order as opposed to the order in which they show in the allocation. For environments that don't exhibit this mapping behavior (e.g., rsh), this won't have any impact.
Also, clean up the vm launch procedure a little bit so it more closely aligns with the state machine implementation that is coming, and remove some lingering "slave" code.
This commit was SVN r25551.
2011-11-30 23:58:24 +04:00
|
|
|
}
|
|
|
|
OPAL_ACQUIRE_THREAD(&lock, &cond, &processing);
|
2010-04-23 08:44:41 +04:00
|
|
|
|
Although we never really thought about it, we made an unconscious assumption in the mapper system - we assumed that the daemons would be placed on nodes in the order that the nodes appear in the allocation. In other words, we assumed that the launch environment would map processes in node order.
Turns out, this isn't necessarily true. The Cray, for example, launches processes in a toroidal pattern, thus causing the daemons to wind up somewhere other than what we thought. Other environments (e.g., slurm) are also capable of such behavior, depending upon the default mapping algorithm they are told to use.
Resolve this problem by making the daemon-to-node assignment in the affected environments when the daemon calls back and tells us what node it is on. Order the nodes in the mapping list so they are in daemon-vpid order as opposed to the order in which they show in the allocation. For environments that don't exhibit this mapping behavior (e.g., rsh), this won't have any impact.
Also, clean up the vm launch procedure a little bit so it more closely aligns with the state machine implementation that is coming, and remove some lingering "slave" code.
This commit was SVN r25551.
2011-11-30 23:58:24 +04:00
|
|
|
job = jdata->jobid;
|
2009-07-19 22:07:04 +04:00
|
|
|
|
Although we never really thought about it, we made an unconscious assumption in the mapper system - we assumed that the daemons would be placed on nodes in the order that the nodes appear in the allocation. In other words, we assumed that the launch environment would map processes in node order.
Turns out, this isn't necessarily true. The Cray, for example, launches processes in a toroidal pattern, thus causing the daemons to wind up somewhere other than what we thought. Other environments (e.g., slurm) are also capable of such behavior, depending upon the default mapping algorithm they are told to use.
Resolve this problem by making the daemon-to-node assignment in the affected environments when the daemon calls back and tells us what node it is on. Order the nodes in the mapping list so they are in daemon-vpid order as opposed to the order in which they show in the allocation. For environments that don't exhibit this mapping behavior (e.g., rsh), this won't have any impact.
Also, clean up the vm launch procedure a little bit so it more closely aligns with the state machine implementation that is coming, and remove some lingering "slave" code.
This commit was SVN r25551.
2011-11-30 23:58:24 +04:00
|
|
|
/* output debugger proctable, if requested */
|
2012-01-11 19:53:09 +04:00
|
|
|
if (orte_debugger_dump_proctable && !jdata->map->display_map) {
|
Although we never really thought about it, we made an unconscious assumption in the mapper system - we assumed that the daemons would be placed on nodes in the order that the nodes appear in the allocation. In other words, we assumed that the launch environment would map processes in node order.
Turns out, this isn't necessarily true. The Cray, for example, launches processes in a toroidal pattern, thus causing the daemons to wind up somewhere other than what we thought. Other environments (e.g., slurm) are also capable of such behavior, depending upon the default mapping algorithm they are told to use.
Resolve this problem by making the daemon-to-node assignment in the affected environments when the daemon calls back and tells us what node it is on. Order the nodes in the mapping list so they are in daemon-vpid order as opposed to the order in which they show in the allocation. For environments that don't exhibit this mapping behavior (e.g., rsh), this won't have any impact.
Also, clean up the vm launch procedure a little bit so it more closely aligns with the state machine implementation that is coming, and remove some lingering "slave" code.
This commit was SVN r25551.
2011-11-30 23:58:24 +04:00
|
|
|
char *output;
|
|
|
|
opal_dss.print(&output, NULL, jdata->map, ORTE_JOB_MAP);
|
|
|
|
if (orte_xml_output) {
|
|
|
|
fprintf(orte_xml_fp, "%s\n", output);
|
|
|
|
fflush(orte_xml_fp);
|
|
|
|
} else {
|
|
|
|
opal_output(orte_clean_output, "%s", output);
|
2009-02-06 18:31:33 +03:00
|
|
|
}
|
Although we never really thought about it, we made an unconscious assumption in the mapper system - we assumed that the daemons would be placed on nodes in the order that the nodes appear in the allocation. In other words, we assumed that the launch environment would map processes in node order.
Turns out, this isn't necessarily true. The Cray, for example, launches processes in a toroidal pattern, thus causing the daemons to wind up somewhere other than what we thought. Other environments (e.g., slurm) are also capable of such behavior, depending upon the default mapping algorithm they are told to use.
Resolve this problem by making the daemon-to-node assignment in the affected environments when the daemon calls back and tells us what node it is on. Order the nodes in the mapping list so they are in daemon-vpid order as opposed to the order in which they show in the allocation. For environments that don't exhibit this mapping behavior (e.g., rsh), this won't have any impact.
Also, clean up the vm launch procedure a little bit so it more closely aligns with the state machine implementation that is coming, and remove some lingering "slave" code.
This commit was SVN r25551.
2011-11-30 23:58:24 +04:00
|
|
|
free(output);
|
2010-07-01 23:37:53 +04:00
|
|
|
}
|
Although we never really thought about it, we made an unconscious assumption in the mapper system - we assumed that the daemons would be placed on nodes in the order that the nodes appear in the allocation. In other words, we assumed that the launch environment would map processes in node order.
Turns out, this isn't necessarily true. The Cray, for example, launches processes in a toroidal pattern, thus causing the daemons to wind up somewhere other than what we thought. Other environments (e.g., slurm) are also capable of such behavior, depending upon the default mapping algorithm they are told to use.
Resolve this problem by making the daemon-to-node assignment in the affected environments when the daemon calls back and tells us what node it is on. Order the nodes in the mapping list so they are in daemon-vpid order as opposed to the order in which they show in the allocation. For environments that don't exhibit this mapping behavior (e.g., rsh), this won't have any impact.
Also, clean up the vm launch procedure a little bit so it more closely aligns with the state machine implementation that is coming, and remove some lingering "slave" code.
This commit was SVN r25551.
2011-11-30 23:58:24 +04:00
|
|
|
|
|
|
|
/* return the favor so that any repetitive comm_spawns track each other */
|
|
|
|
parent->bookmark = jdata->bookmark;
|
2008-02-28 22:58:32 +03:00
|
|
|
|
2010-07-01 23:37:53 +04:00
|
|
|
/* if the child is an ORTE job, wait for the procs to report they are alive */
|
|
|
|
if (!(jdata->controls & ORTE_JOB_CONTROL_NON_ORTE_JOB)) {
|
2008-06-09 18:53:58 +04:00
|
|
|
OPAL_OUTPUT_VERBOSE((5, orte_plm_globals.output,
|
2010-07-01 23:37:53 +04:00
|
|
|
"%s plm:base:receive waiting for procs to report",
|
|
|
|
ORTE_NAME_PRINT(ORTE_PROC_MY_NAME)));
|
|
|
|
OPAL_RELEASE_THREAD(&lock, &cond, &processing);
|
|
|
|
/* we will wait here until the thread is released,
|
|
|
|
* indicating that all procs have reported
|
|
|
|
*/
|
2010-08-28 18:03:17 +04:00
|
|
|
OPAL_ACQUIRE_THREAD(&jdata->dyn_spawn_lock,
|
|
|
|
&jdata->dyn_spawn_cond,
|
|
|
|
&jdata->dyn_spawn_active);
|
|
|
|
OPAL_THREAD_UNLOCK(&jdata->dyn_spawn_lock);
|
2010-07-01 23:37:53 +04:00
|
|
|
OPAL_ACQUIRE_THREAD(&lock, &cond, &processing);
|
|
|
|
}
|
2008-02-28 04:57:57 +03:00
|
|
|
|
2010-07-01 23:37:53 +04:00
|
|
|
ANSWER_LAUNCH:
|
|
|
|
OPAL_OUTPUT_VERBOSE((5, orte_plm_globals.output,
|
|
|
|
"%s plm:base:receive job %s launched",
|
|
|
|
ORTE_NAME_PRINT(ORTE_PROC_MY_NAME),
|
|
|
|
ORTE_JOBID_PRINT(job)));
|
2009-07-19 22:07:04 +04:00
|
|
|
|
2010-07-01 23:37:53 +04:00
|
|
|
/* pack the jobid to be returned */
|
|
|
|
if (ORTE_SUCCESS != (ret = opal_dss.pack(&answer, &job, 1, ORTE_JOBID))) {
|
|
|
|
ORTE_ERROR_LOG(ret);
|
|
|
|
}
|
2009-07-19 22:07:04 +04:00
|
|
|
|
2010-07-01 23:37:53 +04:00
|
|
|
/* send the response back to the sender */
|
|
|
|
if (0 > (ret = orte_rml.send_buffer(&msgpkt->sender, &answer, ORTE_RML_TAG_PLM_PROXY, 0))) {
|
|
|
|
ORTE_ERROR_LOG(ret);
|
|
|
|
}
|
|
|
|
break;
|
|
|
|
|
|
|
|
case ORTE_PLM_UPDATE_PROC_STATE:
|
|
|
|
OPAL_OUTPUT_VERBOSE((5, orte_plm_globals.output,
|
|
|
|
"%s plm:base:receive update proc state command from %s",
|
|
|
|
ORTE_NAME_PRINT(ORTE_PROC_MY_NAME),
|
|
|
|
ORTE_NAME_PRINT(&(msgpkt->sender)) ));
|
|
|
|
count = 1;
|
|
|
|
running = false;
|
|
|
|
while (ORTE_SUCCESS == (rc = opal_dss.unpack(msgpkt->buffer, &job, &count, ORTE_JOBID))) {
|
|
|
|
|
2009-07-19 22:07:04 +04:00
|
|
|
OPAL_OUTPUT_VERBOSE((5, orte_plm_globals.output,
|
2010-07-01 23:37:53 +04:00
|
|
|
"%s plm:base:receive got update_proc_state for job %s",
|
2010-03-10 03:23:24 +03:00
|
|
|
ORTE_NAME_PRINT(ORTE_PROC_MY_NAME),
|
2010-07-01 23:37:53 +04:00
|
|
|
ORTE_JOBID_PRINT(job)));
|
2008-02-28 04:57:57 +03:00
|
|
|
|
2010-07-01 23:37:53 +04:00
|
|
|
name.jobid = job;
|
|
|
|
running = false;
|
|
|
|
/* get the job object */
|
|
|
|
if (NULL == (jdata = orte_get_job_data_object(job))) {
|
|
|
|
ORTE_ERROR_LOG(ORTE_ERR_NOT_FOUND);
|
|
|
|
goto CLEANUP;
|
|
|
|
}
|
|
|
|
/* if we are timing, the daemon will have included the time it
|
|
|
|
* recvd the launch msg - the maximum time between when we sent
|
|
|
|
* that message and a daemon recvd it tells us the time reqd
|
|
|
|
* to wireup the daemon comm network
|
|
|
|
*/
|
|
|
|
if (orte_timing) {
|
|
|
|
int64_t tmpsec, tmpusec;
|
|
|
|
count = 1;
|
|
|
|
if (ORTE_SUCCESS != (rc = opal_dss.unpack(msgpkt->buffer, &tmpsec, &count, OPAL_INT64))) {
|
|
|
|
ORTE_ERROR_LOG(rc);
|
2010-04-23 19:14:21 +04:00
|
|
|
goto CLEANUP;
|
|
|
|
}
|
2010-07-01 23:37:53 +04:00
|
|
|
count = 1;
|
|
|
|
if (ORTE_SUCCESS != (rc = opal_dss.unpack(msgpkt->buffer, &tmpusec, &count, OPAL_INT64))) {
|
|
|
|
ORTE_ERROR_LOG(rc);
|
|
|
|
goto CLEANUP;
|
|
|
|
}
|
|
|
|
/* keep the maximum time */
|
|
|
|
if (tmpsec > jdata->max_launch_msg_recvd.tv_sec) {
|
|
|
|
jdata->max_launch_msg_recvd.tv_sec = tmpsec;
|
|
|
|
jdata->max_launch_msg_recvd.tv_usec = tmpusec;
|
|
|
|
} else if (tmpsec == jdata->max_launch_msg_recvd.tv_sec &&
|
|
|
|
tmpusec > jdata->max_launch_msg_recvd.tv_usec) {
|
|
|
|
jdata->max_launch_msg_recvd.tv_usec = tmpusec;
|
|
|
|
}
|
|
|
|
if (orte_timing_details) {
|
|
|
|
int64_t sec, usec;
|
|
|
|
char *timestr;
|
|
|
|
ORTE_COMPUTE_TIME_DIFF(sec, usec, jdata->launch_msg_sent.tv_sec, jdata->launch_msg_sent.tv_usec,
|
|
|
|
tmpsec, tmpusec);
|
|
|
|
timestr = orte_pretty_print_timing(sec, usec);
|
|
|
|
fprintf(orte_timing_output, "Time for launch msg to reach daemon %s: %s\n",
|
|
|
|
ORTE_VPID_PRINT(msgpkt->sender.vpid), timestr);
|
|
|
|
free(timestr);
|
|
|
|
}
|
|
|
|
}
|
|
|
|
count = 1;
|
|
|
|
while (ORTE_SUCCESS == (rc = opal_dss.unpack(msgpkt->buffer, &vpid, &count, ORTE_VPID))) {
|
|
|
|
if (ORTE_VPID_INVALID == vpid) {
|
|
|
|
/* flag indicates that this job is complete - move on */
|
|
|
|
break;
|
|
|
|
}
|
|
|
|
name.vpid = vpid;
|
2011-08-27 02:16:14 +04:00
|
|
|
ORTE_EPOCH_SET(name.epoch,orte_ess.proc_get_epoch(&name));
|
2011-06-24 00:38:02 +04:00
|
|
|
|
2010-07-01 23:37:53 +04:00
|
|
|
/* unpack the pid */
|
|
|
|
count = 1;
|
|
|
|
if (ORTE_SUCCESS != (rc = opal_dss.unpack(msgpkt->buffer, &pid, &count, OPAL_PID))) {
|
|
|
|
ORTE_ERROR_LOG(rc);
|
|
|
|
goto CLEANUP;
|
|
|
|
}
|
|
|
|
/* if we are timing things, unpack the time this proc was started */
|
2010-04-23 08:44:41 +04:00
|
|
|
if (orte_timing) {
|
|
|
|
int64_t tmpsec, tmpusec;
|
|
|
|
count = 1;
|
|
|
|
if (ORTE_SUCCESS != (rc = opal_dss.unpack(msgpkt->buffer, &tmpsec, &count, OPAL_INT64))) {
|
|
|
|
ORTE_ERROR_LOG(rc);
|
|
|
|
goto CLEANUP;
|
|
|
|
}
|
|
|
|
count = 1;
|
|
|
|
if (ORTE_SUCCESS != (rc = opal_dss.unpack(msgpkt->buffer, &tmpusec, &count, OPAL_INT64))) {
|
|
|
|
ORTE_ERROR_LOG(rc);
|
|
|
|
goto CLEANUP;
|
|
|
|
}
|
|
|
|
if (orte_timing_details) {
|
2010-07-01 23:37:53 +04:00
|
|
|
time_t tmptime;
|
|
|
|
char *tmpstr;
|
|
|
|
tmptime = tmpsec;
|
|
|
|
tmpstr = ctime(&tmptime);
|
|
|
|
/* remove the newline and the year at the end */
|
|
|
|
tmpstr[strlen(tmpstr)-6] = '\0';
|
|
|
|
fprintf(orte_timing_output, "Time rank %s was launched: %s.%3lu\n",
|
|
|
|
ORTE_VPID_PRINT(vpid), tmpstr, (unsigned long)(tmpusec/1000));
|
2010-04-23 08:44:41 +04:00
|
|
|
}
|
2009-07-19 22:07:04 +04:00
|
|
|
}
|
2010-07-01 23:37:53 +04:00
|
|
|
/* unpack the state */
|
2009-07-19 22:07:04 +04:00
|
|
|
count = 1;
|
2010-07-01 23:37:53 +04:00
|
|
|
if (ORTE_SUCCESS != (rc = opal_dss.unpack(msgpkt->buffer, &state, &count, ORTE_PROC_STATE))) {
|
|
|
|
ORTE_ERROR_LOG(rc);
|
|
|
|
goto CLEANUP;
|
|
|
|
}
|
|
|
|
if (ORTE_PROC_STATE_RUNNING == state) {
|
|
|
|
running = true;
|
2008-02-28 04:57:57 +03:00
|
|
|
}
|
2010-07-01 23:37:53 +04:00
|
|
|
/* unpack the exit code */
|
2009-07-19 22:07:04 +04:00
|
|
|
count = 1;
|
2010-07-01 23:37:53 +04:00
|
|
|
if (ORTE_SUCCESS != (rc = opal_dss.unpack(msgpkt->buffer, &exit_code, &count, ORTE_EXIT_CODE))) {
|
|
|
|
ORTE_ERROR_LOG(rc);
|
|
|
|
goto CLEANUP;
|
2010-04-23 08:44:41 +04:00
|
|
|
}
|
2010-07-01 23:37:53 +04:00
|
|
|
|
|
|
|
OPAL_OUTPUT_VERBOSE((5, orte_plm_globals.output,
|
|
|
|
"%s plm:base:receive got update_proc_state for vpid %lu state %s exit_code %d",
|
|
|
|
ORTE_NAME_PRINT(ORTE_PROC_MY_NAME),
|
|
|
|
(unsigned long)vpid, orte_proc_state_to_str(state), (int)exit_code));
|
|
|
|
|
|
|
|
/* update the state */
|
|
|
|
OPAL_RELEASE_THREAD(&lock, &cond, &processing);
|
|
|
|
orte_errmgr.update_state(job, ORTE_JOB_STATE_UNDEF,
|
|
|
|
&name, state, pid, exit_code);
|
|
|
|
OPAL_ACQUIRE_THREAD(&lock, &cond, &processing);
|
|
|
|
}
|
|
|
|
count = 1;
|
|
|
|
}
|
2011-11-23 01:24:35 +04:00
|
|
|
if (ORTE_ERR_UNPACK_READ_PAST_END_OF_BUFFER != rc) {
|
2010-07-01 23:37:53 +04:00
|
|
|
ORTE_ERROR_LOG(rc);
|
|
|
|
} else {
|
|
|
|
rc = ORTE_SUCCESS;
|
|
|
|
}
|
|
|
|
jdata->num_daemons_reported++;
|
|
|
|
if (orte_report_launch_progress && running) {
|
|
|
|
if (0 == jdata->num_daemons_reported % 100 || jdata->num_daemons_reported == orte_process_info.num_procs) {
|
|
|
|
opal_output(orte_clean_output, "Reported: %d (out of %d) daemons - %d (out of %d) procs",
|
|
|
|
(int)jdata->num_daemons_reported, (int)orte_process_info.num_procs,
|
|
|
|
(int)jdata->num_launched, (int)jdata->num_procs);
|
2010-04-23 08:44:41 +04:00
|
|
|
}
|
2010-07-01 23:37:53 +04:00
|
|
|
}
|
|
|
|
break;
|
2009-07-19 22:07:04 +04:00
|
|
|
|
2010-07-01 23:37:53 +04:00
|
|
|
case ORTE_PLM_INIT_ROUTES_CMD:
|
2011-06-24 00:38:02 +04:00
|
|
|
OPAL_OUTPUT_VERBOSE((5, orte_plm_globals.output,
|
|
|
|
"%s plm:base:receive init routes command",
|
|
|
|
ORTE_NAME_PRINT(ORTE_PROC_MY_NAME)));
|
2010-07-01 23:37:53 +04:00
|
|
|
count=1;
|
|
|
|
if (ORTE_SUCCESS != (rc = opal_dss.unpack(msgpkt->buffer, &job, &count, ORTE_JOBID))) {
|
|
|
|
ORTE_ERROR_LOG(rc);
|
|
|
|
goto CLEANUP;
|
|
|
|
}
|
|
|
|
name.jobid = job;
|
|
|
|
count=1;
|
|
|
|
while (ORTE_SUCCESS == opal_dss.unpack(msgpkt->buffer, &vpid, &count, ORTE_VPID)) {
|
|
|
|
if (ORTE_VPID_INVALID == vpid) {
|
|
|
|
break;
|
2010-04-23 08:44:41 +04:00
|
|
|
}
|
2010-07-01 23:37:53 +04:00
|
|
|
name.vpid = vpid;
|
2011-06-24 00:38:02 +04:00
|
|
|
|
2011-08-27 02:16:14 +04:00
|
|
|
#if ORTE_ENABLE_EPOCH
|
2011-06-24 00:38:02 +04:00
|
|
|
count=1;
|
|
|
|
opal_dss.unpack(msgpkt->buffer, &epoch, &count, ORTE_EPOCH);
|
|
|
|
name.epoch = epoch;
|
2011-08-27 02:16:14 +04:00
|
|
|
#endif
|
2011-06-24 00:38:02 +04:00
|
|
|
|
|
|
|
OPAL_OUTPUT_VERBOSE((5, orte_plm_globals.output,
|
|
|
|
"%s plm:base:receive Described rank %s",
|
|
|
|
ORTE_NAME_PRINT(ORTE_PROC_MY_NAME),
|
|
|
|
ORTE_NAME_PRINT(&name)));
|
2010-07-01 23:37:53 +04:00
|
|
|
/* update the errmgr state */
|
|
|
|
orte_errmgr.update_state(job, ORTE_JOB_STATE_REGISTERED,
|
|
|
|
&name, ORTE_PROC_STATE_REGISTERED,
|
|
|
|
0, ORTE_ERROR_DEFAULT_EXIT_CODE);
|
2010-04-23 08:44:41 +04:00
|
|
|
count=1;
|
2010-07-01 23:37:53 +04:00
|
|
|
}
|
|
|
|
/* pass the remainder of the buffer to the active module's
|
|
|
|
* init_routes API
|
|
|
|
*/
|
|
|
|
if (ORTE_SUCCESS != (rc = orte_routed.init_routes(job, msgpkt->buffer))) {
|
|
|
|
ORTE_ERROR_LOG(rc);
|
|
|
|
}
|
2011-06-24 00:38:02 +04:00
|
|
|
|
|
|
|
OPAL_OUTPUT_VERBOSE((5, orte_plm_globals.output,
|
|
|
|
"%s plm:base:receive done with init routes command",
|
|
|
|
ORTE_NAME_PRINT(ORTE_PROC_MY_NAME)));
|
|
|
|
|
2010-07-01 23:37:53 +04:00
|
|
|
break;
|
2010-04-23 08:44:41 +04:00
|
|
|
|
2010-07-01 23:37:53 +04:00
|
|
|
default:
|
2011-06-24 00:38:02 +04:00
|
|
|
OPAL_OUTPUT_VERBOSE((5, orte_plm_globals.output,
|
|
|
|
"%s plm:base:receive unknown command",
|
|
|
|
ORTE_NAME_PRINT(ORTE_PROC_MY_NAME)));
|
2010-07-01 23:37:53 +04:00
|
|
|
ORTE_ERROR_LOG(ORTE_ERR_VALUE_OUT_OF_BOUNDS);
|
|
|
|
rc = ORTE_ERR_VALUE_OUT_OF_BOUNDS;
|
|
|
|
break;
|
2009-07-19 22:07:04 +04:00
|
|
|
}
|
|
|
|
|
|
|
|
CLEANUP:
|
|
|
|
/* release the message */
|
|
|
|
OBJ_RELEASE(msgpkt);
|
|
|
|
OBJ_DESTRUCT(&answer);
|
|
|
|
if (ORTE_SUCCESS != rc) {
|
|
|
|
goto DEPART;
|
|
|
|
}
|
2008-02-28 04:57:57 +03:00
|
|
|
}
|
2009-07-19 22:07:04 +04:00
|
|
|
|
2010-07-01 23:37:53 +04:00
|
|
|
DEPART:
|
2009-07-19 22:07:04 +04:00
|
|
|
/* release the thread */
|
2010-04-23 08:44:41 +04:00
|
|
|
OPAL_RELEASE_THREAD(&lock, &cond, &processing);
|
2008-02-28 04:57:57 +03:00
|
|
|
|
2009-02-09 23:44:44 +03:00
|
|
|
/* see if an error occurred - if so, wakeup the HNP so we can exit */
|
2009-05-04 15:07:40 +04:00
|
|
|
if (ORTE_PROC_IS_HNP && ORTE_SUCCESS != rc) {
|
2010-07-18 01:03:27 +04:00
|
|
|
orte_jobs_complete();
|
2008-02-28 04:57:57 +03:00
|
|
|
}
|
2011-06-24 00:38:02 +04:00
|
|
|
|
|
|
|
OPAL_OUTPUT_VERBOSE((5, orte_plm_globals.output,
|
|
|
|
"%s plm:base:receive done processing commands",
|
|
|
|
ORTE_NAME_PRINT(ORTE_PROC_MY_NAME)));
|
2008-02-28 22:58:32 +03:00
|
|
|
}
|
|
|
|
|
|
|
|
/*
|
|
|
|
* handle message from proxies
|
|
|
|
* NOTE: The incoming buffer "buffer" is OBJ_RELEASED by the calling program.
|
|
|
|
* DO NOT RELEASE THIS BUFFER IN THIS CODE
|
|
|
|
*/
|
|
|
|
|
|
|
|
void orte_plm_base_recv(int status, orte_process_name_t* sender,
|
|
|
|
opal_buffer_t* buffer, orte_rml_tag_t tag,
|
|
|
|
void* cbdata)
|
|
|
|
{
|
|
|
|
int rc;
|
2008-02-28 04:57:57 +03:00
|
|
|
|
2008-06-09 18:53:58 +04:00
|
|
|
OPAL_OUTPUT_VERBOSE((5, orte_plm_globals.output,
|
2008-02-28 22:58:32 +03:00
|
|
|
"%s plm:base:receive got message from %s",
|
2009-03-06 00:50:47 +03:00
|
|
|
ORTE_NAME_PRINT(ORTE_PROC_MY_NAME),
|
|
|
|
ORTE_NAME_PRINT(sender)));
|
2008-02-28 22:58:32 +03:00
|
|
|
|
|
|
|
/* don't process this right away - we need to get out of the recv before
|
|
|
|
* we process the message as it may ask us to do something that involves
|
|
|
|
* more messaging! Instead, setup an event so that the message gets processed
|
|
|
|
* as soon as we leave the recv.
|
|
|
|
*
|
|
|
|
* The macro makes a copy of the buffer, which we release above - the incoming
|
|
|
|
* buffer, however, is NOT released here, although its payload IS transferred
|
|
|
|
* to the message buffer for later processing
|
|
|
|
*/
|
2009-07-19 22:07:04 +04:00
|
|
|
ORTE_PROCESS_MESSAGE(&recvs, &lock, processing, ready_fd[1], true, sender, &buffer);
|
|
|
|
|
2008-02-28 22:58:32 +03:00
|
|
|
/* reissue the recv */
|
|
|
|
if (ORTE_SUCCESS != (rc = orte_rml.recv_buffer_nb(ORTE_NAME_WILDCARD,
|
|
|
|
ORTE_RML_TAG_PLM,
|
|
|
|
ORTE_RML_NON_PERSISTENT,
|
|
|
|
orte_plm_base_recv,
|
|
|
|
NULL))) {
|
|
|
|
ORTE_ERROR_LOG(rc);
|
|
|
|
}
|
2009-07-17 06:28:47 +04:00
|
|
|
|
2008-02-28 04:57:57 +03:00
|
|
|
return;
|
|
|
|
}
|
|
|
|
|
2009-07-19 22:07:04 +04:00
|
|
|
/* where HNP messages come */
|
|
|
|
void orte_plm_base_receive_process_msg(int fd, short event, void *data)
|
|
|
|
{
|
|
|
|
orte_message_event_t *mev = (orte_message_event_t*)data;
|
|
|
|
|
|
|
|
ORTE_PROCESS_MESSAGE(&recvs, &lock, processing, ready_fd[1], false, &mev->sender, &mev->buffer);
|
|
|
|
OBJ_RELEASE(mev);
|
|
|
|
}
|