2006-02-07 06:32:36 +03:00
|
|
|
/* -*- C -*-
|
|
|
|
*
|
2007-03-17 02:11:45 +03:00
|
|
|
* Copyright (c) 2004-2007 The Trustees of Indiana University and Indiana
|
2006-02-07 06:32:36 +03:00
|
|
|
* University Research and Technology
|
|
|
|
* Corporation. All rights reserved.
|
2006-08-23 07:32:36 +04:00
|
|
|
* Copyright (c) 2004-2006 The University of Tennessee and The University
|
2006-02-07 06:32:36 +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$
|
|
|
|
*
|
|
|
|
*/
|
|
|
|
#ifndef ORTE_DSS_INTERNAL_H_
|
|
|
|
#define ORTE_DSS_INTERNAL_H_
|
|
|
|
|
|
|
|
#include "orte_config.h"
|
|
|
|
|
2006-02-12 04:33:29 +03:00
|
|
|
#include "orte/orte_constants.h"
|
|
|
|
#include "orte/class/orte_pointer_array.h"
|
2006-02-07 06:32:36 +03:00
|
|
|
|
2006-02-12 04:33:29 +03:00
|
|
|
#include "orte/dss/dss.h"
|
2006-02-07 06:32:36 +03:00
|
|
|
|
|
|
|
#if HAVE_STRING_H
|
|
|
|
# if !defined(STDC_HEADERS) && HAVE_MEMORY_H
|
|
|
|
# include <memory.h>
|
|
|
|
# endif
|
|
|
|
# include <string.h>
|
|
|
|
#endif
|
|
|
|
|
|
|
|
#if defined(c_plusplus) || defined(__cplusplus)
|
|
|
|
extern "C" {
|
|
|
|
#endif
|
|
|
|
|
|
|
|
/*
|
2007-04-06 23:40:29 +04:00
|
|
|
* The default starting chunk size
|
2006-02-07 06:32:36 +03:00
|
|
|
*/
|
2007-04-06 23:40:29 +04:00
|
|
|
#define ORTE_DSS_DEFAULT_INITIAL_SIZE 128
|
|
|
|
/*
|
|
|
|
* The default threshold size when we switch from doubling the
|
|
|
|
* buffer size to addatively increasing it
|
|
|
|
*/
|
|
|
|
#define ORTE_DSS_DEFAULT_THRESHOLD_SIZE 1024
|
2006-03-30 18:33:25 +04:00
|
|
|
|
|
|
|
/*
|
|
|
|
* Internal type corresponding to size_t. Do not use this in
|
|
|
|
* interface calls - use ORTE_SIZE instead.
|
|
|
|
*/
|
|
|
|
#if SIZEOF_SIZE_T == 1
|
|
|
|
#define DSS_TYPE_SIZE_T ORTE_UINT8
|
|
|
|
#elif SIZEOF_SIZE_T == 2
|
|
|
|
#define DSS_TYPE_SIZE_T ORTE_UINT16
|
|
|
|
#elif SIZEOF_SIZE_T == 4
|
|
|
|
#define DSS_TYPE_SIZE_T ORTE_UINT32
|
|
|
|
#elif SIZEOF_SIZE_T == 8
|
|
|
|
#define DSS_TYPE_SIZE_T ORTE_UINT64
|
|
|
|
#else
|
|
|
|
#error Unsupported size_t size!
|
|
|
|
#endif
|
|
|
|
|
|
|
|
/*
|
|
|
|
* Internal type corresponding to bool. Do not use this in interface
|
|
|
|
* calls - use ORTE_BOOL instead.
|
|
|
|
*/
|
|
|
|
#if SIZEOF_BOOL == 1
|
|
|
|
#define DSS_TYPE_BOOL ORTE_UINT8
|
|
|
|
#elif SIZEOF_BOOL == 2
|
|
|
|
#define DSS_TYPE_BOOL ORTE_UINT16
|
|
|
|
#elif SIZEOF_BOOL == 4
|
|
|
|
#define DSS_TYPE_BOOL ORTE_UINT32
|
|
|
|
#elif SIZEOF_BOOL == 8
|
|
|
|
#define DSS_TYPE_BOOL ORTE_UINT64
|
|
|
|
#else
|
|
|
|
#error Unsupported bool size!
|
|
|
|
#endif
|
|
|
|
|
|
|
|
/*
|
|
|
|
* Internal type corresponding to int and unsigned int. Do not use
|
|
|
|
* this in interface calls - use ORTE_INT / ORTE_UINT instead.
|
|
|
|
*/
|
|
|
|
#if SIZEOF_INT == 1
|
|
|
|
#define DSS_TYPE_INT ORTE_INT8
|
|
|
|
#define DSS_TYPE_UINT ORTE_UINT8
|
|
|
|
#elif SIZEOF_INT == 2
|
|
|
|
#define DSS_TYPE_INT ORTE_INT16
|
|
|
|
#define DSS_TYPE_UINT ORTE_UINT16
|
|
|
|
#elif SIZEOF_INT == 4
|
|
|
|
#define DSS_TYPE_INT ORTE_INT32
|
|
|
|
#define DSS_TYPE_UINT ORTE_UINT32
|
|
|
|
#elif SIZEOF_INT == 8
|
|
|
|
#define DSS_TYPE_INT ORTE_INT64
|
|
|
|
#define DSS_TYPE_UINT ORTE_UINT64
|
|
|
|
#else
|
|
|
|
#error Unsupported int size!
|
|
|
|
#endif
|
|
|
|
|
|
|
|
/*
|
|
|
|
* Internal type corresponding to pid_t. Do not use this in interface
|
|
|
|
* calls - use ORTE_PID instead.
|
|
|
|
*/
|
|
|
|
#if SIZEOF_PID_T == 1
|
|
|
|
#define DSS_TYPE_PID_T ORTE_UINT8
|
|
|
|
#elif SIZEOF_PID_T == 2
|
|
|
|
#define DSS_TYPE_PID_T ORTE_UINT16
|
|
|
|
#elif SIZEOF_PID_T == 4
|
|
|
|
#define DSS_TYPE_PID_T ORTE_UINT32
|
|
|
|
#elif SIZEOF_PID_T == 8
|
|
|
|
#define DSS_TYPE_PID_T ORTE_UINT64
|
|
|
|
#else
|
|
|
|
#error Unsupported pid_t size!
|
|
|
|
#endif
|
|
|
|
|
2006-09-15 01:29:51 +04:00
|
|
|
/* Unpack generic size macros */
|
|
|
|
#define UNPACK_SIZE_MISMATCH(unpack_type, remote_type, ret) \
|
|
|
|
do { \
|
|
|
|
switch(remote_type) { \
|
|
|
|
case ORTE_UINT8: \
|
|
|
|
UNPACK_SIZE_MISMATCH_FOUND(unpack_type, uint8_t, remote_type); \
|
|
|
|
break; \
|
|
|
|
case ORTE_INT8: \
|
|
|
|
UNPACK_SIZE_MISMATCH_FOUND(unpack_type, int8_t, remote_type); \
|
|
|
|
break; \
|
|
|
|
case ORTE_UINT16: \
|
|
|
|
UNPACK_SIZE_MISMATCH_FOUND(unpack_type, uint16_t, remote_type); \
|
|
|
|
break; \
|
|
|
|
case ORTE_INT16: \
|
|
|
|
UNPACK_SIZE_MISMATCH_FOUND(unpack_type, int16_t, remote_type); \
|
|
|
|
break; \
|
|
|
|
case ORTE_UINT32: \
|
|
|
|
UNPACK_SIZE_MISMATCH_FOUND(unpack_type, uint32_t, remote_type); \
|
|
|
|
break; \
|
|
|
|
case ORTE_INT32: \
|
|
|
|
UNPACK_SIZE_MISMATCH_FOUND(unpack_type, int32_t, remote_type); \
|
|
|
|
break; \
|
|
|
|
case ORTE_UINT64: \
|
|
|
|
UNPACK_SIZE_MISMATCH_FOUND(unpack_type, uint64_t, remote_type); \
|
|
|
|
break; \
|
|
|
|
case ORTE_INT64: \
|
|
|
|
UNPACK_SIZE_MISMATCH_FOUND(unpack_type, int64_t, remote_type); \
|
|
|
|
break; \
|
|
|
|
default: \
|
|
|
|
ret = ORTE_ERR_NOT_FOUND; \
|
|
|
|
ORTE_ERROR_LOG(ret); \
|
|
|
|
} \
|
|
|
|
} while (0)
|
|
|
|
|
|
|
|
/* NOTE: do not need to deal with endianness here, as the unpacking of
|
|
|
|
the underling sender-side type will do that for us. Repeat: the
|
|
|
|
data in tmpbuf[] is already in host byte order. */
|
|
|
|
#define UNPACK_SIZE_MISMATCH_FOUND(unpack_type, tmptype, tmpdsstype) \
|
|
|
|
do { \
|
|
|
|
orte_std_cntr_t i; \
|
|
|
|
tmptype *tmpbuf = (tmptype*)malloc(sizeof(tmptype) * (*num_vals)); \
|
|
|
|
ret = orte_dss_unpack_buffer(buffer, tmpbuf, num_vals, tmpdsstype); \
|
|
|
|
for (i = 0 ; i < *num_vals ; ++i) { \
|
|
|
|
((unpack_type*) dest)[i] = (unpack_type)(tmpbuf[i]); \
|
|
|
|
} \
|
|
|
|
free(tmpbuf); \
|
|
|
|
} while (0)
|
|
|
|
|
|
|
|
|
2006-02-07 06:32:36 +03:00
|
|
|
/**
|
|
|
|
* Internal struct used for holding registered dss functions
|
|
|
|
*/
|
|
|
|
struct orte_dss_type_info_t {
|
|
|
|
opal_object_t super;
|
|
|
|
/* type identifier */
|
|
|
|
orte_data_type_t odti_type;
|
|
|
|
/** Debugging string name */
|
|
|
|
char *odti_name;
|
|
|
|
/** Pack function */
|
|
|
|
orte_dss_pack_fn_t odti_pack_fn;
|
|
|
|
/** Unpack function */
|
|
|
|
orte_dss_unpack_fn_t odti_unpack_fn;
|
|
|
|
/** copy function */
|
|
|
|
orte_dss_copy_fn_t odti_copy_fn;
|
|
|
|
/** compare function */
|
|
|
|
orte_dss_compare_fn_t odti_compare_fn;
|
|
|
|
/** size function */
|
|
|
|
orte_dss_size_fn_t odti_size_fn;
|
|
|
|
/** print function */
|
|
|
|
orte_dss_print_fn_t odti_print_fn;
|
|
|
|
/** Release function */
|
|
|
|
orte_dss_release_fn_t odti_release_fn;
|
|
|
|
/** flag to indicate structured data */
|
|
|
|
bool odti_structured;
|
|
|
|
};
|
|
|
|
/**
|
|
|
|
* Convenience typedef
|
|
|
|
*/
|
|
|
|
typedef struct orte_dss_type_info_t orte_dss_type_info_t;
|
2006-08-23 07:32:36 +04:00
|
|
|
ORTE_DECLSPEC OBJ_CLASS_DECLARATION(orte_dss_type_info_t);
|
2006-02-07 06:32:36 +03:00
|
|
|
|
|
|
|
/*
|
|
|
|
* globals needed within dss
|
|
|
|
*/
|
|
|
|
extern bool orte_dss_initialized;
|
|
|
|
extern bool orte_dss_debug;
|
|
|
|
extern int orte_dss_verbose;
|
2007-04-06 23:40:29 +04:00
|
|
|
extern int orte_dss_initial_size;
|
|
|
|
extern int orte_dss_threshold_size;
|
2006-02-07 06:32:36 +03:00
|
|
|
extern orte_pointer_array_t *orte_dss_types;
|
|
|
|
extern orte_data_type_t orte_dss_num_reg_types;
|
|
|
|
|
|
|
|
/*
|
|
|
|
* Implementations of API functions
|
|
|
|
*/
|
Bring over the ORTE 2.0 DSS. This introduces a few changes, almost all of which are transparent to the user:
1. Introduces a flag for the type of buffer that now allows a user to either have a fully described or a completely non-described buffer. In the latter case, no data type descriptions are included in the buffer. This obviously limits what we can do for debugging purposes, but the intent here was to provide an optimized communications capability for those wanting it.
Note that individual buffers can be designated for either type using the orte_dss.set_buffer_type command. In other words, the buffer type can be set dynamically - it isn't a configuration setting at all. The type will default to fully described. A buffer MUST be empty to set its type - this is checked by the set_buffer_type command, and you will receive an error if you violate that rule.
IMPORTANT NOTE: ORTE 1.x actually will NOT work with non-described buffers. This capability should therefore NOT be used until we tell you it is okay. For now, it is here simply so we can begin bringing over parts of ORTE 2.0. The problem is that ORTE 1.x depends upon the transmission of non-hard-cast data types such as size_t. These "soft" types currently utilize a "peek" function to see their actual type in the buffer - obviously, without description, the system has no idea how to unpack these "soft" types. We will deal with this later - for now, please don't use the non-described buffer option.
2. Introduces the orte_std_cntr_t type. This will become the replacement for the size_t's used throughout ORTE 1.x. At the moment, it is actually typedef'd to size_t for backward compatibility.
3. Introduces the orte_dss.arith API that supports arbitrary arithmetic functions on numeric data types. Calling the function with any other data type will generate an error.
This commit was SVN r11075.
2006-08-01 22:42:25 +04:00
|
|
|
|
2006-02-07 06:32:36 +03:00
|
|
|
int orte_dss_set(orte_data_value_t *value, void *new_value, orte_data_type_t type);
|
|
|
|
|
|
|
|
int orte_dss_get(void **data, orte_data_value_t *value, orte_data_type_t type);
|
|
|
|
|
Bring over the ORTE 2.0 DSS. This introduces a few changes, almost all of which are transparent to the user:
1. Introduces a flag for the type of buffer that now allows a user to either have a fully described or a completely non-described buffer. In the latter case, no data type descriptions are included in the buffer. This obviously limits what we can do for debugging purposes, but the intent here was to provide an optimized communications capability for those wanting it.
Note that individual buffers can be designated for either type using the orte_dss.set_buffer_type command. In other words, the buffer type can be set dynamically - it isn't a configuration setting at all. The type will default to fully described. A buffer MUST be empty to set its type - this is checked by the set_buffer_type command, and you will receive an error if you violate that rule.
IMPORTANT NOTE: ORTE 1.x actually will NOT work with non-described buffers. This capability should therefore NOT be used until we tell you it is okay. For now, it is here simply so we can begin bringing over parts of ORTE 2.0. The problem is that ORTE 1.x depends upon the transmission of non-hard-cast data types such as size_t. These "soft" types currently utilize a "peek" function to see their actual type in the buffer - obviously, without description, the system has no idea how to unpack these "soft" types. We will deal with this later - for now, please don't use the non-described buffer option.
2. Introduces the orte_std_cntr_t type. This will become the replacement for the size_t's used throughout ORTE 1.x. At the moment, it is actually typedef'd to size_t for backward compatibility.
3. Introduces the orte_dss.arith API that supports arbitrary arithmetic functions on numeric data types. Calling the function with any other data type will generate an error.
This commit was SVN r11075.
2006-08-01 22:42:25 +04:00
|
|
|
int orte_dss_arith(orte_data_value_t *value, orte_data_value_t *operand, orte_dss_arith_op_t operation);
|
2006-02-07 06:32:36 +03:00
|
|
|
|
|
|
|
int orte_dss_increment(orte_data_value_t *value);
|
|
|
|
|
|
|
|
int orte_dss_decrement(orte_data_value_t *value);
|
|
|
|
|
Bring over the ORTE 2.0 DSS. This introduces a few changes, almost all of which are transparent to the user:
1. Introduces a flag for the type of buffer that now allows a user to either have a fully described or a completely non-described buffer. In the latter case, no data type descriptions are included in the buffer. This obviously limits what we can do for debugging purposes, but the intent here was to provide an optimized communications capability for those wanting it.
Note that individual buffers can be designated for either type using the orte_dss.set_buffer_type command. In other words, the buffer type can be set dynamically - it isn't a configuration setting at all. The type will default to fully described. A buffer MUST be empty to set its type - this is checked by the set_buffer_type command, and you will receive an error if you violate that rule.
IMPORTANT NOTE: ORTE 1.x actually will NOT work with non-described buffers. This capability should therefore NOT be used until we tell you it is okay. For now, it is here simply so we can begin bringing over parts of ORTE 2.0. The problem is that ORTE 1.x depends upon the transmission of non-hard-cast data types such as size_t. These "soft" types currently utilize a "peek" function to see their actual type in the buffer - obviously, without description, the system has no idea how to unpack these "soft" types. We will deal with this later - for now, please don't use the non-described buffer option.
2. Introduces the orte_std_cntr_t type. This will become the replacement for the size_t's used throughout ORTE 1.x. At the moment, it is actually typedef'd to size_t for backward compatibility.
3. Introduces the orte_dss.arith API that supports arbitrary arithmetic functions on numeric data types. Calling the function with any other data type will generate an error.
This commit was SVN r11075.
2006-08-01 22:42:25 +04:00
|
|
|
int orte_dss_set_buffer_type(orte_buffer_t *buffer, orte_dss_buffer_type_t type);
|
|
|
|
|
2006-02-07 06:32:36 +03:00
|
|
|
int orte_dss_pack(orte_buffer_t *buffer, void *src,
|
Bring over the ORTE 2.0 DSS. This introduces a few changes, almost all of which are transparent to the user:
1. Introduces a flag for the type of buffer that now allows a user to either have a fully described or a completely non-described buffer. In the latter case, no data type descriptions are included in the buffer. This obviously limits what we can do for debugging purposes, but the intent here was to provide an optimized communications capability for those wanting it.
Note that individual buffers can be designated for either type using the orte_dss.set_buffer_type command. In other words, the buffer type can be set dynamically - it isn't a configuration setting at all. The type will default to fully described. A buffer MUST be empty to set its type - this is checked by the set_buffer_type command, and you will receive an error if you violate that rule.
IMPORTANT NOTE: ORTE 1.x actually will NOT work with non-described buffers. This capability should therefore NOT be used until we tell you it is okay. For now, it is here simply so we can begin bringing over parts of ORTE 2.0. The problem is that ORTE 1.x depends upon the transmission of non-hard-cast data types such as size_t. These "soft" types currently utilize a "peek" function to see their actual type in the buffer - obviously, without description, the system has no idea how to unpack these "soft" types. We will deal with this later - for now, please don't use the non-described buffer option.
2. Introduces the orte_std_cntr_t type. This will become the replacement for the size_t's used throughout ORTE 1.x. At the moment, it is actually typedef'd to size_t for backward compatibility.
3. Introduces the orte_dss.arith API that supports arbitrary arithmetic functions on numeric data types. Calling the function with any other data type will generate an error.
This commit was SVN r11075.
2006-08-01 22:42:25 +04:00
|
|
|
orte_std_cntr_t num_vals,
|
2006-02-07 06:32:36 +03:00
|
|
|
orte_data_type_t type);
|
|
|
|
int orte_dss_unpack(orte_buffer_t *buffer, void *dest,
|
Bring over the ORTE 2.0 DSS. This introduces a few changes, almost all of which are transparent to the user:
1. Introduces a flag for the type of buffer that now allows a user to either have a fully described or a completely non-described buffer. In the latter case, no data type descriptions are included in the buffer. This obviously limits what we can do for debugging purposes, but the intent here was to provide an optimized communications capability for those wanting it.
Note that individual buffers can be designated for either type using the orte_dss.set_buffer_type command. In other words, the buffer type can be set dynamically - it isn't a configuration setting at all. The type will default to fully described. A buffer MUST be empty to set its type - this is checked by the set_buffer_type command, and you will receive an error if you violate that rule.
IMPORTANT NOTE: ORTE 1.x actually will NOT work with non-described buffers. This capability should therefore NOT be used until we tell you it is okay. For now, it is here simply so we can begin bringing over parts of ORTE 2.0. The problem is that ORTE 1.x depends upon the transmission of non-hard-cast data types such as size_t. These "soft" types currently utilize a "peek" function to see their actual type in the buffer - obviously, without description, the system has no idea how to unpack these "soft" types. We will deal with this later - for now, please don't use the non-described buffer option.
2. Introduces the orte_std_cntr_t type. This will become the replacement for the size_t's used throughout ORTE 1.x. At the moment, it is actually typedef'd to size_t for backward compatibility.
3. Introduces the orte_dss.arith API that supports arbitrary arithmetic functions on numeric data types. Calling the function with any other data type will generate an error.
This commit was SVN r11075.
2006-08-01 22:42:25 +04:00
|
|
|
orte_std_cntr_t *max_num_vals,
|
2006-02-07 06:32:36 +03:00
|
|
|
orte_data_type_t type);
|
|
|
|
|
|
|
|
int orte_dss_copy(void **dest, void *src, orte_data_type_t type);
|
|
|
|
|
|
|
|
int orte_dss_compare(void *value1, void *value2,
|
|
|
|
orte_data_type_t type);
|
|
|
|
|
|
|
|
int orte_dss_print(char **output, char *prefix, void *src, orte_data_type_t type);
|
|
|
|
|
2006-10-03 12:40:35 +04:00
|
|
|
int orte_dss_dump(int output_stream, void *src, orte_data_type_t type);
|
|
|
|
|
2006-02-07 06:32:36 +03:00
|
|
|
int orte_dss_size(size_t *size, void *src, orte_data_type_t type);
|
|
|
|
|
|
|
|
int orte_dss_peek(orte_buffer_t *buffer, orte_data_type_t *type,
|
Bring over the ORTE 2.0 DSS. This introduces a few changes, almost all of which are transparent to the user:
1. Introduces a flag for the type of buffer that now allows a user to either have a fully described or a completely non-described buffer. In the latter case, no data type descriptions are included in the buffer. This obviously limits what we can do for debugging purposes, but the intent here was to provide an optimized communications capability for those wanting it.
Note that individual buffers can be designated for either type using the orte_dss.set_buffer_type command. In other words, the buffer type can be set dynamically - it isn't a configuration setting at all. The type will default to fully described. A buffer MUST be empty to set its type - this is checked by the set_buffer_type command, and you will receive an error if you violate that rule.
IMPORTANT NOTE: ORTE 1.x actually will NOT work with non-described buffers. This capability should therefore NOT be used until we tell you it is okay. For now, it is here simply so we can begin bringing over parts of ORTE 2.0. The problem is that ORTE 1.x depends upon the transmission of non-hard-cast data types such as size_t. These "soft" types currently utilize a "peek" function to see their actual type in the buffer - obviously, without description, the system has no idea how to unpack these "soft" types. We will deal with this later - for now, please don't use the non-described buffer option.
2. Introduces the orte_std_cntr_t type. This will become the replacement for the size_t's used throughout ORTE 1.x. At the moment, it is actually typedef'd to size_t for backward compatibility.
3. Introduces the orte_dss.arith API that supports arbitrary arithmetic functions on numeric data types. Calling the function with any other data type will generate an error.
This commit was SVN r11075.
2006-08-01 22:42:25 +04:00
|
|
|
orte_std_cntr_t *number);
|
2006-02-07 06:32:36 +03:00
|
|
|
|
|
|
|
int orte_dss_peek_type(orte_buffer_t *buffer, orte_data_type_t *type);
|
|
|
|
|
|
|
|
int orte_dss_unload(orte_buffer_t *buffer, void **payload,
|
2006-08-15 23:54:10 +04:00
|
|
|
orte_std_cntr_t *bytes_used);
|
|
|
|
int orte_dss_load(orte_buffer_t *buffer, void *payload, orte_std_cntr_t bytes_used);
|
2006-02-07 06:32:36 +03:00
|
|
|
|
Commit the orted-failed-to-start code. This correctly causes the system to detect the failure of an orted to start and allows the system to terminate all procs/orteds that *did* start.
The primary change that underlies all this is in the OOB. Specifically, the problem in the code until now has been that the OOB attempts to resolve an address when we call the "send" to an unknown recipient. The OOB would then wait forever if that recipient never actually started (and hence, never reported back its OOB contact info). In the case of an orted that failed to start, we would correctly detect that the orted hadn't started, but then we would attempt to order all orteds (including the one that failed to start) to die. This would cause the OOB to "hang" the system.
Unfortunately, revising how the OOB resolves addresses introduced a number of additional problems. Specifically, and most troublesome, was the fact that comm_spawn involved the immediate transmission of the rendezvous point from parent-to-child after the child was spawned. The current code used the OOB address resolution as a "barrier" - basically, the parent would attempt to send the info to the child, and then "hold" there until the child's contact info had arrived (meaning the child had started) and the send could be completed.
Note that this also caused comm_spawn to "hang" the entire system if the child never started... The app-failed-to-start helped improve that behavior - this code provides additional relief.
With this change, the OOB will return an ADDRESSEE_UNKNOWN error if you attempt to send to a recipient whose contact info isn't already in the OOB's hash tables. To resolve comm_spawn issues, we also now force the cross-sharing of connection info between parent and child jobs during spawn.
Finally, to aid in setting triggers to the right values, we introduce the "arith" API for the GPR. This function allows you to atomically change the value in a registry location (either divide, multiply, add, or subtract) by the provided operand. It is equivalent to first fetching the value using a "get", then modifying it, and then putting the result back into the registry via a "put".
This commit was SVN r14711.
2007-05-21 22:31:28 +04:00
|
|
|
int orte_dss_xfer_payload(orte_buffer_t *dest, orte_buffer_t *src);
|
|
|
|
|
|
|
|
int orte_dss_copy_payload(orte_buffer_t *dest, orte_buffer_t *src);
|
|
|
|
|
2006-02-07 06:32:36 +03:00
|
|
|
int orte_dss_register(orte_dss_pack_fn_t pack_fn,
|
|
|
|
orte_dss_unpack_fn_t unpack_fn,
|
|
|
|
orte_dss_copy_fn_t copy_fn,
|
|
|
|
orte_dss_compare_fn_t compare_fn,
|
|
|
|
orte_dss_size_fn_t size_fn,
|
|
|
|
orte_dss_print_fn_t print_fn,
|
|
|
|
orte_dss_release_fn_t release_fn,
|
|
|
|
bool structured,
|
|
|
|
const char *name, orte_data_type_t *type);
|
|
|
|
|
|
|
|
void orte_dss_release(orte_data_value_t *value);
|
|
|
|
|
|
|
|
char *orte_dss_lookup_data_type(orte_data_type_t type);
|
|
|
|
|
|
|
|
void orte_dss_dump_data_types(int output);
|
|
|
|
|
|
|
|
/*
|
|
|
|
* Non-API functions
|
|
|
|
*/
|
Bring over the ORTE 2.0 DSS. This introduces a few changes, almost all of which are transparent to the user:
1. Introduces a flag for the type of buffer that now allows a user to either have a fully described or a completely non-described buffer. In the latter case, no data type descriptions are included in the buffer. This obviously limits what we can do for debugging purposes, but the intent here was to provide an optimized communications capability for those wanting it.
Note that individual buffers can be designated for either type using the orte_dss.set_buffer_type command. In other words, the buffer type can be set dynamically - it isn't a configuration setting at all. The type will default to fully described. A buffer MUST be empty to set its type - this is checked by the set_buffer_type command, and you will receive an error if you violate that rule.
IMPORTANT NOTE: ORTE 1.x actually will NOT work with non-described buffers. This capability should therefore NOT be used until we tell you it is okay. For now, it is here simply so we can begin bringing over parts of ORTE 2.0. The problem is that ORTE 1.x depends upon the transmission of non-hard-cast data types such as size_t. These "soft" types currently utilize a "peek" function to see their actual type in the buffer - obviously, without description, the system has no idea how to unpack these "soft" types. We will deal with this later - for now, please don't use the non-described buffer option.
2. Introduces the orte_std_cntr_t type. This will become the replacement for the size_t's used throughout ORTE 1.x. At the moment, it is actually typedef'd to size_t for backward compatibility.
3. Introduces the orte_dss.arith API that supports arbitrary arithmetic functions on numeric data types. Calling the function with any other data type will generate an error.
This commit was SVN r11075.
2006-08-01 22:42:25 +04:00
|
|
|
int orte_dss_pack_buffer(orte_buffer_t *buffer, void *src, orte_std_cntr_t num_vals,
|
2006-02-07 06:32:36 +03:00
|
|
|
orte_data_type_t type);
|
|
|
|
|
Bring over the ORTE 2.0 DSS. This introduces a few changes, almost all of which are transparent to the user:
1. Introduces a flag for the type of buffer that now allows a user to either have a fully described or a completely non-described buffer. In the latter case, no data type descriptions are included in the buffer. This obviously limits what we can do for debugging purposes, but the intent here was to provide an optimized communications capability for those wanting it.
Note that individual buffers can be designated for either type using the orte_dss.set_buffer_type command. In other words, the buffer type can be set dynamically - it isn't a configuration setting at all. The type will default to fully described. A buffer MUST be empty to set its type - this is checked by the set_buffer_type command, and you will receive an error if you violate that rule.
IMPORTANT NOTE: ORTE 1.x actually will NOT work with non-described buffers. This capability should therefore NOT be used until we tell you it is okay. For now, it is here simply so we can begin bringing over parts of ORTE 2.0. The problem is that ORTE 1.x depends upon the transmission of non-hard-cast data types such as size_t. These "soft" types currently utilize a "peek" function to see their actual type in the buffer - obviously, without description, the system has no idea how to unpack these "soft" types. We will deal with this later - for now, please don't use the non-described buffer option.
2. Introduces the orte_std_cntr_t type. This will become the replacement for the size_t's used throughout ORTE 1.x. At the moment, it is actually typedef'd to size_t for backward compatibility.
3. Introduces the orte_dss.arith API that supports arbitrary arithmetic functions on numeric data types. Calling the function with any other data type will generate an error.
This commit was SVN r11075.
2006-08-01 22:42:25 +04:00
|
|
|
int orte_dss_unpack_buffer(orte_buffer_t *buffer, void *dst, orte_std_cntr_t *num_vals,
|
2006-02-07 06:32:36 +03:00
|
|
|
orte_data_type_t type);
|
|
|
|
|
|
|
|
/*
|
|
|
|
* Internal pack functions
|
|
|
|
*/
|
|
|
|
|
|
|
|
int orte_dss_pack_null(orte_buffer_t *buffer, void *src,
|
Bring over the ORTE 2.0 DSS. This introduces a few changes, almost all of which are transparent to the user:
1. Introduces a flag for the type of buffer that now allows a user to either have a fully described or a completely non-described buffer. In the latter case, no data type descriptions are included in the buffer. This obviously limits what we can do for debugging purposes, but the intent here was to provide an optimized communications capability for those wanting it.
Note that individual buffers can be designated for either type using the orte_dss.set_buffer_type command. In other words, the buffer type can be set dynamically - it isn't a configuration setting at all. The type will default to fully described. A buffer MUST be empty to set its type - this is checked by the set_buffer_type command, and you will receive an error if you violate that rule.
IMPORTANT NOTE: ORTE 1.x actually will NOT work with non-described buffers. This capability should therefore NOT be used until we tell you it is okay. For now, it is here simply so we can begin bringing over parts of ORTE 2.0. The problem is that ORTE 1.x depends upon the transmission of non-hard-cast data types such as size_t. These "soft" types currently utilize a "peek" function to see their actual type in the buffer - obviously, without description, the system has no idea how to unpack these "soft" types. We will deal with this later - for now, please don't use the non-described buffer option.
2. Introduces the orte_std_cntr_t type. This will become the replacement for the size_t's used throughout ORTE 1.x. At the moment, it is actually typedef'd to size_t for backward compatibility.
3. Introduces the orte_dss.arith API that supports arbitrary arithmetic functions on numeric data types. Calling the function with any other data type will generate an error.
This commit was SVN r11075.
2006-08-01 22:42:25 +04:00
|
|
|
orte_std_cntr_t num_vals, orte_data_type_t type);
|
2006-02-07 06:32:36 +03:00
|
|
|
int orte_dss_pack_byte(orte_buffer_t *buffer, void *src,
|
Bring over the ORTE 2.0 DSS. This introduces a few changes, almost all of which are transparent to the user:
1. Introduces a flag for the type of buffer that now allows a user to either have a fully described or a completely non-described buffer. In the latter case, no data type descriptions are included in the buffer. This obviously limits what we can do for debugging purposes, but the intent here was to provide an optimized communications capability for those wanting it.
Note that individual buffers can be designated for either type using the orte_dss.set_buffer_type command. In other words, the buffer type can be set dynamically - it isn't a configuration setting at all. The type will default to fully described. A buffer MUST be empty to set its type - this is checked by the set_buffer_type command, and you will receive an error if you violate that rule.
IMPORTANT NOTE: ORTE 1.x actually will NOT work with non-described buffers. This capability should therefore NOT be used until we tell you it is okay. For now, it is here simply so we can begin bringing over parts of ORTE 2.0. The problem is that ORTE 1.x depends upon the transmission of non-hard-cast data types such as size_t. These "soft" types currently utilize a "peek" function to see their actual type in the buffer - obviously, without description, the system has no idea how to unpack these "soft" types. We will deal with this later - for now, please don't use the non-described buffer option.
2. Introduces the orte_std_cntr_t type. This will become the replacement for the size_t's used throughout ORTE 1.x. At the moment, it is actually typedef'd to size_t for backward compatibility.
3. Introduces the orte_dss.arith API that supports arbitrary arithmetic functions on numeric data types. Calling the function with any other data type will generate an error.
This commit was SVN r11075.
2006-08-01 22:42:25 +04:00
|
|
|
orte_std_cntr_t num_vals, orte_data_type_t type);
|
2006-02-07 06:32:36 +03:00
|
|
|
|
|
|
|
int orte_dss_pack_bool(orte_buffer_t *buffer, void *src,
|
Bring over the ORTE 2.0 DSS. This introduces a few changes, almost all of which are transparent to the user:
1. Introduces a flag for the type of buffer that now allows a user to either have a fully described or a completely non-described buffer. In the latter case, no data type descriptions are included in the buffer. This obviously limits what we can do for debugging purposes, but the intent here was to provide an optimized communications capability for those wanting it.
Note that individual buffers can be designated for either type using the orte_dss.set_buffer_type command. In other words, the buffer type can be set dynamically - it isn't a configuration setting at all. The type will default to fully described. A buffer MUST be empty to set its type - this is checked by the set_buffer_type command, and you will receive an error if you violate that rule.
IMPORTANT NOTE: ORTE 1.x actually will NOT work with non-described buffers. This capability should therefore NOT be used until we tell you it is okay. For now, it is here simply so we can begin bringing over parts of ORTE 2.0. The problem is that ORTE 1.x depends upon the transmission of non-hard-cast data types such as size_t. These "soft" types currently utilize a "peek" function to see their actual type in the buffer - obviously, without description, the system has no idea how to unpack these "soft" types. We will deal with this later - for now, please don't use the non-described buffer option.
2. Introduces the orte_std_cntr_t type. This will become the replacement for the size_t's used throughout ORTE 1.x. At the moment, it is actually typedef'd to size_t for backward compatibility.
3. Introduces the orte_dss.arith API that supports arbitrary arithmetic functions on numeric data types. Calling the function with any other data type will generate an error.
This commit was SVN r11075.
2006-08-01 22:42:25 +04:00
|
|
|
orte_std_cntr_t num_vals, orte_data_type_t type);
|
2006-02-07 06:32:36 +03:00
|
|
|
|
|
|
|
int orte_dss_pack_int(orte_buffer_t *buffer, void *src,
|
Bring over the ORTE 2.0 DSS. This introduces a few changes, almost all of which are transparent to the user:
1. Introduces a flag for the type of buffer that now allows a user to either have a fully described or a completely non-described buffer. In the latter case, no data type descriptions are included in the buffer. This obviously limits what we can do for debugging purposes, but the intent here was to provide an optimized communications capability for those wanting it.
Note that individual buffers can be designated for either type using the orte_dss.set_buffer_type command. In other words, the buffer type can be set dynamically - it isn't a configuration setting at all. The type will default to fully described. A buffer MUST be empty to set its type - this is checked by the set_buffer_type command, and you will receive an error if you violate that rule.
IMPORTANT NOTE: ORTE 1.x actually will NOT work with non-described buffers. This capability should therefore NOT be used until we tell you it is okay. For now, it is here simply so we can begin bringing over parts of ORTE 2.0. The problem is that ORTE 1.x depends upon the transmission of non-hard-cast data types such as size_t. These "soft" types currently utilize a "peek" function to see their actual type in the buffer - obviously, without description, the system has no idea how to unpack these "soft" types. We will deal with this later - for now, please don't use the non-described buffer option.
2. Introduces the orte_std_cntr_t type. This will become the replacement for the size_t's used throughout ORTE 1.x. At the moment, it is actually typedef'd to size_t for backward compatibility.
3. Introduces the orte_dss.arith API that supports arbitrary arithmetic functions on numeric data types. Calling the function with any other data type will generate an error.
This commit was SVN r11075.
2006-08-01 22:42:25 +04:00
|
|
|
orte_std_cntr_t num_vals, orte_data_type_t type);
|
2006-02-07 06:32:36 +03:00
|
|
|
int orte_dss_pack_int16(orte_buffer_t *buffer, void *src,
|
Bring over the ORTE 2.0 DSS. This introduces a few changes, almost all of which are transparent to the user:
1. Introduces a flag for the type of buffer that now allows a user to either have a fully described or a completely non-described buffer. In the latter case, no data type descriptions are included in the buffer. This obviously limits what we can do for debugging purposes, but the intent here was to provide an optimized communications capability for those wanting it.
Note that individual buffers can be designated for either type using the orte_dss.set_buffer_type command. In other words, the buffer type can be set dynamically - it isn't a configuration setting at all. The type will default to fully described. A buffer MUST be empty to set its type - this is checked by the set_buffer_type command, and you will receive an error if you violate that rule.
IMPORTANT NOTE: ORTE 1.x actually will NOT work with non-described buffers. This capability should therefore NOT be used until we tell you it is okay. For now, it is here simply so we can begin bringing over parts of ORTE 2.0. The problem is that ORTE 1.x depends upon the transmission of non-hard-cast data types such as size_t. These "soft" types currently utilize a "peek" function to see their actual type in the buffer - obviously, without description, the system has no idea how to unpack these "soft" types. We will deal with this later - for now, please don't use the non-described buffer option.
2. Introduces the orte_std_cntr_t type. This will become the replacement for the size_t's used throughout ORTE 1.x. At the moment, it is actually typedef'd to size_t for backward compatibility.
3. Introduces the orte_dss.arith API that supports arbitrary arithmetic functions on numeric data types. Calling the function with any other data type will generate an error.
This commit was SVN r11075.
2006-08-01 22:42:25 +04:00
|
|
|
orte_std_cntr_t num_vals, orte_data_type_t type);
|
2006-02-07 06:32:36 +03:00
|
|
|
int orte_dss_pack_int32(orte_buffer_t *buffer, void *src,
|
Bring over the ORTE 2.0 DSS. This introduces a few changes, almost all of which are transparent to the user:
1. Introduces a flag for the type of buffer that now allows a user to either have a fully described or a completely non-described buffer. In the latter case, no data type descriptions are included in the buffer. This obviously limits what we can do for debugging purposes, but the intent here was to provide an optimized communications capability for those wanting it.
Note that individual buffers can be designated for either type using the orte_dss.set_buffer_type command. In other words, the buffer type can be set dynamically - it isn't a configuration setting at all. The type will default to fully described. A buffer MUST be empty to set its type - this is checked by the set_buffer_type command, and you will receive an error if you violate that rule.
IMPORTANT NOTE: ORTE 1.x actually will NOT work with non-described buffers. This capability should therefore NOT be used until we tell you it is okay. For now, it is here simply so we can begin bringing over parts of ORTE 2.0. The problem is that ORTE 1.x depends upon the transmission of non-hard-cast data types such as size_t. These "soft" types currently utilize a "peek" function to see their actual type in the buffer - obviously, without description, the system has no idea how to unpack these "soft" types. We will deal with this later - for now, please don't use the non-described buffer option.
2. Introduces the orte_std_cntr_t type. This will become the replacement for the size_t's used throughout ORTE 1.x. At the moment, it is actually typedef'd to size_t for backward compatibility.
3. Introduces the orte_dss.arith API that supports arbitrary arithmetic functions on numeric data types. Calling the function with any other data type will generate an error.
This commit was SVN r11075.
2006-08-01 22:42:25 +04:00
|
|
|
orte_std_cntr_t num_vals, orte_data_type_t type);
|
2006-02-07 06:32:36 +03:00
|
|
|
int orte_dss_pack_int64(orte_buffer_t *buffer, void *src,
|
Bring over the ORTE 2.0 DSS. This introduces a few changes, almost all of which are transparent to the user:
1. Introduces a flag for the type of buffer that now allows a user to either have a fully described or a completely non-described buffer. In the latter case, no data type descriptions are included in the buffer. This obviously limits what we can do for debugging purposes, but the intent here was to provide an optimized communications capability for those wanting it.
Note that individual buffers can be designated for either type using the orte_dss.set_buffer_type command. In other words, the buffer type can be set dynamically - it isn't a configuration setting at all. The type will default to fully described. A buffer MUST be empty to set its type - this is checked by the set_buffer_type command, and you will receive an error if you violate that rule.
IMPORTANT NOTE: ORTE 1.x actually will NOT work with non-described buffers. This capability should therefore NOT be used until we tell you it is okay. For now, it is here simply so we can begin bringing over parts of ORTE 2.0. The problem is that ORTE 1.x depends upon the transmission of non-hard-cast data types such as size_t. These "soft" types currently utilize a "peek" function to see their actual type in the buffer - obviously, without description, the system has no idea how to unpack these "soft" types. We will deal with this later - for now, please don't use the non-described buffer option.
2. Introduces the orte_std_cntr_t type. This will become the replacement for the size_t's used throughout ORTE 1.x. At the moment, it is actually typedef'd to size_t for backward compatibility.
3. Introduces the orte_dss.arith API that supports arbitrary arithmetic functions on numeric data types. Calling the function with any other data type will generate an error.
This commit was SVN r11075.
2006-08-01 22:42:25 +04:00
|
|
|
orte_std_cntr_t num_vals, orte_data_type_t type);
|
2006-02-07 06:32:36 +03:00
|
|
|
|
|
|
|
int orte_dss_pack_sizet(orte_buffer_t *buffer, void *src,
|
Bring over the ORTE 2.0 DSS. This introduces a few changes, almost all of which are transparent to the user:
1. Introduces a flag for the type of buffer that now allows a user to either have a fully described or a completely non-described buffer. In the latter case, no data type descriptions are included in the buffer. This obviously limits what we can do for debugging purposes, but the intent here was to provide an optimized communications capability for those wanting it.
Note that individual buffers can be designated for either type using the orte_dss.set_buffer_type command. In other words, the buffer type can be set dynamically - it isn't a configuration setting at all. The type will default to fully described. A buffer MUST be empty to set its type - this is checked by the set_buffer_type command, and you will receive an error if you violate that rule.
IMPORTANT NOTE: ORTE 1.x actually will NOT work with non-described buffers. This capability should therefore NOT be used until we tell you it is okay. For now, it is here simply so we can begin bringing over parts of ORTE 2.0. The problem is that ORTE 1.x depends upon the transmission of non-hard-cast data types such as size_t. These "soft" types currently utilize a "peek" function to see their actual type in the buffer - obviously, without description, the system has no idea how to unpack these "soft" types. We will deal with this later - for now, please don't use the non-described buffer option.
2. Introduces the orte_std_cntr_t type. This will become the replacement for the size_t's used throughout ORTE 1.x. At the moment, it is actually typedef'd to size_t for backward compatibility.
3. Introduces the orte_dss.arith API that supports arbitrary arithmetic functions on numeric data types. Calling the function with any other data type will generate an error.
This commit was SVN r11075.
2006-08-01 22:42:25 +04:00
|
|
|
orte_std_cntr_t num_vals, orte_data_type_t type);
|
2006-02-07 06:32:36 +03:00
|
|
|
|
|
|
|
int orte_dss_pack_pid(orte_buffer_t *buffer, void *src,
|
Bring over the ORTE 2.0 DSS. This introduces a few changes, almost all of which are transparent to the user:
1. Introduces a flag for the type of buffer that now allows a user to either have a fully described or a completely non-described buffer. In the latter case, no data type descriptions are included in the buffer. This obviously limits what we can do for debugging purposes, but the intent here was to provide an optimized communications capability for those wanting it.
Note that individual buffers can be designated for either type using the orte_dss.set_buffer_type command. In other words, the buffer type can be set dynamically - it isn't a configuration setting at all. The type will default to fully described. A buffer MUST be empty to set its type - this is checked by the set_buffer_type command, and you will receive an error if you violate that rule.
IMPORTANT NOTE: ORTE 1.x actually will NOT work with non-described buffers. This capability should therefore NOT be used until we tell you it is okay. For now, it is here simply so we can begin bringing over parts of ORTE 2.0. The problem is that ORTE 1.x depends upon the transmission of non-hard-cast data types such as size_t. These "soft" types currently utilize a "peek" function to see their actual type in the buffer - obviously, without description, the system has no idea how to unpack these "soft" types. We will deal with this later - for now, please don't use the non-described buffer option.
2. Introduces the orte_std_cntr_t type. This will become the replacement for the size_t's used throughout ORTE 1.x. At the moment, it is actually typedef'd to size_t for backward compatibility.
3. Introduces the orte_dss.arith API that supports arbitrary arithmetic functions on numeric data types. Calling the function with any other data type will generate an error.
This commit was SVN r11075.
2006-08-01 22:42:25 +04:00
|
|
|
orte_std_cntr_t num_vals, orte_data_type_t type);
|
2006-02-07 06:32:36 +03:00
|
|
|
|
|
|
|
int orte_dss_pack_string(orte_buffer_t *buffer, void *src,
|
Bring over the ORTE 2.0 DSS. This introduces a few changes, almost all of which are transparent to the user:
1. Introduces a flag for the type of buffer that now allows a user to either have a fully described or a completely non-described buffer. In the latter case, no data type descriptions are included in the buffer. This obviously limits what we can do for debugging purposes, but the intent here was to provide an optimized communications capability for those wanting it.
Note that individual buffers can be designated for either type using the orte_dss.set_buffer_type command. In other words, the buffer type can be set dynamically - it isn't a configuration setting at all. The type will default to fully described. A buffer MUST be empty to set its type - this is checked by the set_buffer_type command, and you will receive an error if you violate that rule.
IMPORTANT NOTE: ORTE 1.x actually will NOT work with non-described buffers. This capability should therefore NOT be used until we tell you it is okay. For now, it is here simply so we can begin bringing over parts of ORTE 2.0. The problem is that ORTE 1.x depends upon the transmission of non-hard-cast data types such as size_t. These "soft" types currently utilize a "peek" function to see their actual type in the buffer - obviously, without description, the system has no idea how to unpack these "soft" types. We will deal with this later - for now, please don't use the non-described buffer option.
2. Introduces the orte_std_cntr_t type. This will become the replacement for the size_t's used throughout ORTE 1.x. At the moment, it is actually typedef'd to size_t for backward compatibility.
3. Introduces the orte_dss.arith API that supports arbitrary arithmetic functions on numeric data types. Calling the function with any other data type will generate an error.
This commit was SVN r11075.
2006-08-01 22:42:25 +04:00
|
|
|
orte_std_cntr_t num_vals, orte_data_type_t type);
|
|
|
|
|
|
|
|
int orte_dss_pack_std_cntr(orte_buffer_t *buffer, void *src, orte_std_cntr_t num,
|
|
|
|
orte_data_type_t type);
|
2006-02-07 06:32:36 +03:00
|
|
|
|
|
|
|
int orte_dss_pack_data_type(orte_buffer_t *buffer, void *src,
|
Bring over the ORTE 2.0 DSS. This introduces a few changes, almost all of which are transparent to the user:
1. Introduces a flag for the type of buffer that now allows a user to either have a fully described or a completely non-described buffer. In the latter case, no data type descriptions are included in the buffer. This obviously limits what we can do for debugging purposes, but the intent here was to provide an optimized communications capability for those wanting it.
Note that individual buffers can be designated for either type using the orte_dss.set_buffer_type command. In other words, the buffer type can be set dynamically - it isn't a configuration setting at all. The type will default to fully described. A buffer MUST be empty to set its type - this is checked by the set_buffer_type command, and you will receive an error if you violate that rule.
IMPORTANT NOTE: ORTE 1.x actually will NOT work with non-described buffers. This capability should therefore NOT be used until we tell you it is okay. For now, it is here simply so we can begin bringing over parts of ORTE 2.0. The problem is that ORTE 1.x depends upon the transmission of non-hard-cast data types such as size_t. These "soft" types currently utilize a "peek" function to see their actual type in the buffer - obviously, without description, the system has no idea how to unpack these "soft" types. We will deal with this later - for now, please don't use the non-described buffer option.
2. Introduces the orte_std_cntr_t type. This will become the replacement for the size_t's used throughout ORTE 1.x. At the moment, it is actually typedef'd to size_t for backward compatibility.
3. Introduces the orte_dss.arith API that supports arbitrary arithmetic functions on numeric data types. Calling the function with any other data type will generate an error.
This commit was SVN r11075.
2006-08-01 22:42:25 +04:00
|
|
|
orte_std_cntr_t num_vals, orte_data_type_t type);
|
2006-02-07 06:32:36 +03:00
|
|
|
|
2007-03-17 02:11:45 +03:00
|
|
|
#if OPAL_ENABLE_FT == 1
|
|
|
|
int orte_dss_pack_ckpt_cmd(orte_buffer_t *buffer, void *src,
|
|
|
|
orte_std_cntr_t num_vals, orte_data_type_t type);
|
|
|
|
#endif
|
|
|
|
|
2006-02-07 06:32:36 +03:00
|
|
|
int orte_dss_pack_data_value(orte_buffer_t *buffer, void *src,
|
Bring over the ORTE 2.0 DSS. This introduces a few changes, almost all of which are transparent to the user:
1. Introduces a flag for the type of buffer that now allows a user to either have a fully described or a completely non-described buffer. In the latter case, no data type descriptions are included in the buffer. This obviously limits what we can do for debugging purposes, but the intent here was to provide an optimized communications capability for those wanting it.
Note that individual buffers can be designated for either type using the orte_dss.set_buffer_type command. In other words, the buffer type can be set dynamically - it isn't a configuration setting at all. The type will default to fully described. A buffer MUST be empty to set its type - this is checked by the set_buffer_type command, and you will receive an error if you violate that rule.
IMPORTANT NOTE: ORTE 1.x actually will NOT work with non-described buffers. This capability should therefore NOT be used until we tell you it is okay. For now, it is here simply so we can begin bringing over parts of ORTE 2.0. The problem is that ORTE 1.x depends upon the transmission of non-hard-cast data types such as size_t. These "soft" types currently utilize a "peek" function to see their actual type in the buffer - obviously, without description, the system has no idea how to unpack these "soft" types. We will deal with this later - for now, please don't use the non-described buffer option.
2. Introduces the orte_std_cntr_t type. This will become the replacement for the size_t's used throughout ORTE 1.x. At the moment, it is actually typedef'd to size_t for backward compatibility.
3. Introduces the orte_dss.arith API that supports arbitrary arithmetic functions on numeric data types. Calling the function with any other data type will generate an error.
This commit was SVN r11075.
2006-08-01 22:42:25 +04:00
|
|
|
orte_std_cntr_t num_vals, orte_data_type_t type);
|
2006-02-07 06:32:36 +03:00
|
|
|
|
|
|
|
int orte_dss_pack_byte_object(orte_buffer_t *buffer, void *src,
|
Bring over the ORTE 2.0 DSS. This introduces a few changes, almost all of which are transparent to the user:
1. Introduces a flag for the type of buffer that now allows a user to either have a fully described or a completely non-described buffer. In the latter case, no data type descriptions are included in the buffer. This obviously limits what we can do for debugging purposes, but the intent here was to provide an optimized communications capability for those wanting it.
Note that individual buffers can be designated for either type using the orte_dss.set_buffer_type command. In other words, the buffer type can be set dynamically - it isn't a configuration setting at all. The type will default to fully described. A buffer MUST be empty to set its type - this is checked by the set_buffer_type command, and you will receive an error if you violate that rule.
IMPORTANT NOTE: ORTE 1.x actually will NOT work with non-described buffers. This capability should therefore NOT be used until we tell you it is okay. For now, it is here simply so we can begin bringing over parts of ORTE 2.0. The problem is that ORTE 1.x depends upon the transmission of non-hard-cast data types such as size_t. These "soft" types currently utilize a "peek" function to see their actual type in the buffer - obviously, without description, the system has no idea how to unpack these "soft" types. We will deal with this later - for now, please don't use the non-described buffer option.
2. Introduces the orte_std_cntr_t type. This will become the replacement for the size_t's used throughout ORTE 1.x. At the moment, it is actually typedef'd to size_t for backward compatibility.
3. Introduces the orte_dss.arith API that supports arbitrary arithmetic functions on numeric data types. Calling the function with any other data type will generate an error.
This commit was SVN r11075.
2006-08-01 22:42:25 +04:00
|
|
|
orte_std_cntr_t num_vals, orte_data_type_t type);
|
2006-02-07 06:32:36 +03:00
|
|
|
|
|
|
|
/*
|
|
|
|
* Internal unpack functions
|
|
|
|
*/
|
|
|
|
|
|
|
|
int orte_dss_unpack_null(orte_buffer_t *buffer, void *dest,
|
Bring over the ORTE 2.0 DSS. This introduces a few changes, almost all of which are transparent to the user:
1. Introduces a flag for the type of buffer that now allows a user to either have a fully described or a completely non-described buffer. In the latter case, no data type descriptions are included in the buffer. This obviously limits what we can do for debugging purposes, but the intent here was to provide an optimized communications capability for those wanting it.
Note that individual buffers can be designated for either type using the orte_dss.set_buffer_type command. In other words, the buffer type can be set dynamically - it isn't a configuration setting at all. The type will default to fully described. A buffer MUST be empty to set its type - this is checked by the set_buffer_type command, and you will receive an error if you violate that rule.
IMPORTANT NOTE: ORTE 1.x actually will NOT work with non-described buffers. This capability should therefore NOT be used until we tell you it is okay. For now, it is here simply so we can begin bringing over parts of ORTE 2.0. The problem is that ORTE 1.x depends upon the transmission of non-hard-cast data types such as size_t. These "soft" types currently utilize a "peek" function to see their actual type in the buffer - obviously, without description, the system has no idea how to unpack these "soft" types. We will deal with this later - for now, please don't use the non-described buffer option.
2. Introduces the orte_std_cntr_t type. This will become the replacement for the size_t's used throughout ORTE 1.x. At the moment, it is actually typedef'd to size_t for backward compatibility.
3. Introduces the orte_dss.arith API that supports arbitrary arithmetic functions on numeric data types. Calling the function with any other data type will generate an error.
This commit was SVN r11075.
2006-08-01 22:42:25 +04:00
|
|
|
orte_std_cntr_t *num_vals, orte_data_type_t type);
|
2006-02-07 06:32:36 +03:00
|
|
|
int orte_dss_unpack_byte(orte_buffer_t *buffer, void *dest,
|
Bring over the ORTE 2.0 DSS. This introduces a few changes, almost all of which are transparent to the user:
1. Introduces a flag for the type of buffer that now allows a user to either have a fully described or a completely non-described buffer. In the latter case, no data type descriptions are included in the buffer. This obviously limits what we can do for debugging purposes, but the intent here was to provide an optimized communications capability for those wanting it.
Note that individual buffers can be designated for either type using the orte_dss.set_buffer_type command. In other words, the buffer type can be set dynamically - it isn't a configuration setting at all. The type will default to fully described. A buffer MUST be empty to set its type - this is checked by the set_buffer_type command, and you will receive an error if you violate that rule.
IMPORTANT NOTE: ORTE 1.x actually will NOT work with non-described buffers. This capability should therefore NOT be used until we tell you it is okay. For now, it is here simply so we can begin bringing over parts of ORTE 2.0. The problem is that ORTE 1.x depends upon the transmission of non-hard-cast data types such as size_t. These "soft" types currently utilize a "peek" function to see their actual type in the buffer - obviously, without description, the system has no idea how to unpack these "soft" types. We will deal with this later - for now, please don't use the non-described buffer option.
2. Introduces the orte_std_cntr_t type. This will become the replacement for the size_t's used throughout ORTE 1.x. At the moment, it is actually typedef'd to size_t for backward compatibility.
3. Introduces the orte_dss.arith API that supports arbitrary arithmetic functions on numeric data types. Calling the function with any other data type will generate an error.
This commit was SVN r11075.
2006-08-01 22:42:25 +04:00
|
|
|
orte_std_cntr_t *num_vals, orte_data_type_t type);
|
2006-02-07 06:32:36 +03:00
|
|
|
|
|
|
|
int orte_dss_unpack_bool(orte_buffer_t *buffer, void *dest,
|
Bring over the ORTE 2.0 DSS. This introduces a few changes, almost all of which are transparent to the user:
1. Introduces a flag for the type of buffer that now allows a user to either have a fully described or a completely non-described buffer. In the latter case, no data type descriptions are included in the buffer. This obviously limits what we can do for debugging purposes, but the intent here was to provide an optimized communications capability for those wanting it.
Note that individual buffers can be designated for either type using the orte_dss.set_buffer_type command. In other words, the buffer type can be set dynamically - it isn't a configuration setting at all. The type will default to fully described. A buffer MUST be empty to set its type - this is checked by the set_buffer_type command, and you will receive an error if you violate that rule.
IMPORTANT NOTE: ORTE 1.x actually will NOT work with non-described buffers. This capability should therefore NOT be used until we tell you it is okay. For now, it is here simply so we can begin bringing over parts of ORTE 2.0. The problem is that ORTE 1.x depends upon the transmission of non-hard-cast data types such as size_t. These "soft" types currently utilize a "peek" function to see their actual type in the buffer - obviously, without description, the system has no idea how to unpack these "soft" types. We will deal with this later - for now, please don't use the non-described buffer option.
2. Introduces the orte_std_cntr_t type. This will become the replacement for the size_t's used throughout ORTE 1.x. At the moment, it is actually typedef'd to size_t for backward compatibility.
3. Introduces the orte_dss.arith API that supports arbitrary arithmetic functions on numeric data types. Calling the function with any other data type will generate an error.
This commit was SVN r11075.
2006-08-01 22:42:25 +04:00
|
|
|
orte_std_cntr_t *num_vals, orte_data_type_t type);
|
2006-02-07 06:32:36 +03:00
|
|
|
|
|
|
|
int orte_dss_unpack_int(orte_buffer_t *buffer, void *dest,
|
Bring over the ORTE 2.0 DSS. This introduces a few changes, almost all of which are transparent to the user:
1. Introduces a flag for the type of buffer that now allows a user to either have a fully described or a completely non-described buffer. In the latter case, no data type descriptions are included in the buffer. This obviously limits what we can do for debugging purposes, but the intent here was to provide an optimized communications capability for those wanting it.
Note that individual buffers can be designated for either type using the orte_dss.set_buffer_type command. In other words, the buffer type can be set dynamically - it isn't a configuration setting at all. The type will default to fully described. A buffer MUST be empty to set its type - this is checked by the set_buffer_type command, and you will receive an error if you violate that rule.
IMPORTANT NOTE: ORTE 1.x actually will NOT work with non-described buffers. This capability should therefore NOT be used until we tell you it is okay. For now, it is here simply so we can begin bringing over parts of ORTE 2.0. The problem is that ORTE 1.x depends upon the transmission of non-hard-cast data types such as size_t. These "soft" types currently utilize a "peek" function to see their actual type in the buffer - obviously, without description, the system has no idea how to unpack these "soft" types. We will deal with this later - for now, please don't use the non-described buffer option.
2. Introduces the orte_std_cntr_t type. This will become the replacement for the size_t's used throughout ORTE 1.x. At the moment, it is actually typedef'd to size_t for backward compatibility.
3. Introduces the orte_dss.arith API that supports arbitrary arithmetic functions on numeric data types. Calling the function with any other data type will generate an error.
This commit was SVN r11075.
2006-08-01 22:42:25 +04:00
|
|
|
orte_std_cntr_t *num_vals, orte_data_type_t type);
|
2006-02-07 06:32:36 +03:00
|
|
|
int orte_dss_unpack_int16(orte_buffer_t *buffer, void *dest,
|
Bring over the ORTE 2.0 DSS. This introduces a few changes, almost all of which are transparent to the user:
1. Introduces a flag for the type of buffer that now allows a user to either have a fully described or a completely non-described buffer. In the latter case, no data type descriptions are included in the buffer. This obviously limits what we can do for debugging purposes, but the intent here was to provide an optimized communications capability for those wanting it.
Note that individual buffers can be designated for either type using the orte_dss.set_buffer_type command. In other words, the buffer type can be set dynamically - it isn't a configuration setting at all. The type will default to fully described. A buffer MUST be empty to set its type - this is checked by the set_buffer_type command, and you will receive an error if you violate that rule.
IMPORTANT NOTE: ORTE 1.x actually will NOT work with non-described buffers. This capability should therefore NOT be used until we tell you it is okay. For now, it is here simply so we can begin bringing over parts of ORTE 2.0. The problem is that ORTE 1.x depends upon the transmission of non-hard-cast data types such as size_t. These "soft" types currently utilize a "peek" function to see their actual type in the buffer - obviously, without description, the system has no idea how to unpack these "soft" types. We will deal with this later - for now, please don't use the non-described buffer option.
2. Introduces the orte_std_cntr_t type. This will become the replacement for the size_t's used throughout ORTE 1.x. At the moment, it is actually typedef'd to size_t for backward compatibility.
3. Introduces the orte_dss.arith API that supports arbitrary arithmetic functions on numeric data types. Calling the function with any other data type will generate an error.
This commit was SVN r11075.
2006-08-01 22:42:25 +04:00
|
|
|
orte_std_cntr_t *num_vals, orte_data_type_t type);
|
2006-02-07 06:32:36 +03:00
|
|
|
int orte_dss_unpack_int32(orte_buffer_t *buffer, void *dest,
|
Bring over the ORTE 2.0 DSS. This introduces a few changes, almost all of which are transparent to the user:
1. Introduces a flag for the type of buffer that now allows a user to either have a fully described or a completely non-described buffer. In the latter case, no data type descriptions are included in the buffer. This obviously limits what we can do for debugging purposes, but the intent here was to provide an optimized communications capability for those wanting it.
Note that individual buffers can be designated for either type using the orte_dss.set_buffer_type command. In other words, the buffer type can be set dynamically - it isn't a configuration setting at all. The type will default to fully described. A buffer MUST be empty to set its type - this is checked by the set_buffer_type command, and you will receive an error if you violate that rule.
IMPORTANT NOTE: ORTE 1.x actually will NOT work with non-described buffers. This capability should therefore NOT be used until we tell you it is okay. For now, it is here simply so we can begin bringing over parts of ORTE 2.0. The problem is that ORTE 1.x depends upon the transmission of non-hard-cast data types such as size_t. These "soft" types currently utilize a "peek" function to see their actual type in the buffer - obviously, without description, the system has no idea how to unpack these "soft" types. We will deal with this later - for now, please don't use the non-described buffer option.
2. Introduces the orte_std_cntr_t type. This will become the replacement for the size_t's used throughout ORTE 1.x. At the moment, it is actually typedef'd to size_t for backward compatibility.
3. Introduces the orte_dss.arith API that supports arbitrary arithmetic functions on numeric data types. Calling the function with any other data type will generate an error.
This commit was SVN r11075.
2006-08-01 22:42:25 +04:00
|
|
|
orte_std_cntr_t *num_vals, orte_data_type_t type);
|
2006-02-07 06:32:36 +03:00
|
|
|
int orte_dss_unpack_int64(orte_buffer_t *buffer, void *dest,
|
Bring over the ORTE 2.0 DSS. This introduces a few changes, almost all of which are transparent to the user:
1. Introduces a flag for the type of buffer that now allows a user to either have a fully described or a completely non-described buffer. In the latter case, no data type descriptions are included in the buffer. This obviously limits what we can do for debugging purposes, but the intent here was to provide an optimized communications capability for those wanting it.
Note that individual buffers can be designated for either type using the orte_dss.set_buffer_type command. In other words, the buffer type can be set dynamically - it isn't a configuration setting at all. The type will default to fully described. A buffer MUST be empty to set its type - this is checked by the set_buffer_type command, and you will receive an error if you violate that rule.
IMPORTANT NOTE: ORTE 1.x actually will NOT work with non-described buffers. This capability should therefore NOT be used until we tell you it is okay. For now, it is here simply so we can begin bringing over parts of ORTE 2.0. The problem is that ORTE 1.x depends upon the transmission of non-hard-cast data types such as size_t. These "soft" types currently utilize a "peek" function to see their actual type in the buffer - obviously, without description, the system has no idea how to unpack these "soft" types. We will deal with this later - for now, please don't use the non-described buffer option.
2. Introduces the orte_std_cntr_t type. This will become the replacement for the size_t's used throughout ORTE 1.x. At the moment, it is actually typedef'd to size_t for backward compatibility.
3. Introduces the orte_dss.arith API that supports arbitrary arithmetic functions on numeric data types. Calling the function with any other data type will generate an error.
This commit was SVN r11075.
2006-08-01 22:42:25 +04:00
|
|
|
orte_std_cntr_t *num_vals, orte_data_type_t type);
|
2006-02-07 06:32:36 +03:00
|
|
|
|
|
|
|
int orte_dss_unpack_sizet(orte_buffer_t *buffer, void *dest,
|
Bring over the ORTE 2.0 DSS. This introduces a few changes, almost all of which are transparent to the user:
1. Introduces a flag for the type of buffer that now allows a user to either have a fully described or a completely non-described buffer. In the latter case, no data type descriptions are included in the buffer. This obviously limits what we can do for debugging purposes, but the intent here was to provide an optimized communications capability for those wanting it.
Note that individual buffers can be designated for either type using the orte_dss.set_buffer_type command. In other words, the buffer type can be set dynamically - it isn't a configuration setting at all. The type will default to fully described. A buffer MUST be empty to set its type - this is checked by the set_buffer_type command, and you will receive an error if you violate that rule.
IMPORTANT NOTE: ORTE 1.x actually will NOT work with non-described buffers. This capability should therefore NOT be used until we tell you it is okay. For now, it is here simply so we can begin bringing over parts of ORTE 2.0. The problem is that ORTE 1.x depends upon the transmission of non-hard-cast data types such as size_t. These "soft" types currently utilize a "peek" function to see their actual type in the buffer - obviously, without description, the system has no idea how to unpack these "soft" types. We will deal with this later - for now, please don't use the non-described buffer option.
2. Introduces the orte_std_cntr_t type. This will become the replacement for the size_t's used throughout ORTE 1.x. At the moment, it is actually typedef'd to size_t for backward compatibility.
3. Introduces the orte_dss.arith API that supports arbitrary arithmetic functions on numeric data types. Calling the function with any other data type will generate an error.
This commit was SVN r11075.
2006-08-01 22:42:25 +04:00
|
|
|
orte_std_cntr_t *num_vals, orte_data_type_t type);
|
2006-02-07 06:32:36 +03:00
|
|
|
|
|
|
|
int orte_dss_unpack_pid(orte_buffer_t *buffer, void *dest,
|
Bring over the ORTE 2.0 DSS. This introduces a few changes, almost all of which are transparent to the user:
1. Introduces a flag for the type of buffer that now allows a user to either have a fully described or a completely non-described buffer. In the latter case, no data type descriptions are included in the buffer. This obviously limits what we can do for debugging purposes, but the intent here was to provide an optimized communications capability for those wanting it.
Note that individual buffers can be designated for either type using the orte_dss.set_buffer_type command. In other words, the buffer type can be set dynamically - it isn't a configuration setting at all. The type will default to fully described. A buffer MUST be empty to set its type - this is checked by the set_buffer_type command, and you will receive an error if you violate that rule.
IMPORTANT NOTE: ORTE 1.x actually will NOT work with non-described buffers. This capability should therefore NOT be used until we tell you it is okay. For now, it is here simply so we can begin bringing over parts of ORTE 2.0. The problem is that ORTE 1.x depends upon the transmission of non-hard-cast data types such as size_t. These "soft" types currently utilize a "peek" function to see their actual type in the buffer - obviously, without description, the system has no idea how to unpack these "soft" types. We will deal with this later - for now, please don't use the non-described buffer option.
2. Introduces the orte_std_cntr_t type. This will become the replacement for the size_t's used throughout ORTE 1.x. At the moment, it is actually typedef'd to size_t for backward compatibility.
3. Introduces the orte_dss.arith API that supports arbitrary arithmetic functions on numeric data types. Calling the function with any other data type will generate an error.
This commit was SVN r11075.
2006-08-01 22:42:25 +04:00
|
|
|
orte_std_cntr_t *num_vals, orte_data_type_t type);
|
2006-02-07 06:32:36 +03:00
|
|
|
|
|
|
|
int orte_dss_unpack_string(orte_buffer_t *buffer, void *dest,
|
Bring over the ORTE 2.0 DSS. This introduces a few changes, almost all of which are transparent to the user:
1. Introduces a flag for the type of buffer that now allows a user to either have a fully described or a completely non-described buffer. In the latter case, no data type descriptions are included in the buffer. This obviously limits what we can do for debugging purposes, but the intent here was to provide an optimized communications capability for those wanting it.
Note that individual buffers can be designated for either type using the orte_dss.set_buffer_type command. In other words, the buffer type can be set dynamically - it isn't a configuration setting at all. The type will default to fully described. A buffer MUST be empty to set its type - this is checked by the set_buffer_type command, and you will receive an error if you violate that rule.
IMPORTANT NOTE: ORTE 1.x actually will NOT work with non-described buffers. This capability should therefore NOT be used until we tell you it is okay. For now, it is here simply so we can begin bringing over parts of ORTE 2.0. The problem is that ORTE 1.x depends upon the transmission of non-hard-cast data types such as size_t. These "soft" types currently utilize a "peek" function to see their actual type in the buffer - obviously, without description, the system has no idea how to unpack these "soft" types. We will deal with this later - for now, please don't use the non-described buffer option.
2. Introduces the orte_std_cntr_t type. This will become the replacement for the size_t's used throughout ORTE 1.x. At the moment, it is actually typedef'd to size_t for backward compatibility.
3. Introduces the orte_dss.arith API that supports arbitrary arithmetic functions on numeric data types. Calling the function with any other data type will generate an error.
This commit was SVN r11075.
2006-08-01 22:42:25 +04:00
|
|
|
orte_std_cntr_t *num_vals, orte_data_type_t type);
|
|
|
|
|
|
|
|
int orte_dss_unpack_std_cntr(orte_buffer_t *buffer, void *dest, orte_std_cntr_t *num,
|
|
|
|
orte_data_type_t type);
|
2006-02-07 06:32:36 +03:00
|
|
|
|
|
|
|
int orte_dss_unpack_data_type(orte_buffer_t *buffer, void *dest,
|
Bring over the ORTE 2.0 DSS. This introduces a few changes, almost all of which are transparent to the user:
1. Introduces a flag for the type of buffer that now allows a user to either have a fully described or a completely non-described buffer. In the latter case, no data type descriptions are included in the buffer. This obviously limits what we can do for debugging purposes, but the intent here was to provide an optimized communications capability for those wanting it.
Note that individual buffers can be designated for either type using the orte_dss.set_buffer_type command. In other words, the buffer type can be set dynamically - it isn't a configuration setting at all. The type will default to fully described. A buffer MUST be empty to set its type - this is checked by the set_buffer_type command, and you will receive an error if you violate that rule.
IMPORTANT NOTE: ORTE 1.x actually will NOT work with non-described buffers. This capability should therefore NOT be used until we tell you it is okay. For now, it is here simply so we can begin bringing over parts of ORTE 2.0. The problem is that ORTE 1.x depends upon the transmission of non-hard-cast data types such as size_t. These "soft" types currently utilize a "peek" function to see their actual type in the buffer - obviously, without description, the system has no idea how to unpack these "soft" types. We will deal with this later - for now, please don't use the non-described buffer option.
2. Introduces the orte_std_cntr_t type. This will become the replacement for the size_t's used throughout ORTE 1.x. At the moment, it is actually typedef'd to size_t for backward compatibility.
3. Introduces the orte_dss.arith API that supports arbitrary arithmetic functions on numeric data types. Calling the function with any other data type will generate an error.
This commit was SVN r11075.
2006-08-01 22:42:25 +04:00
|
|
|
orte_std_cntr_t *num_vals, orte_data_type_t type);
|
2006-02-07 06:32:36 +03:00
|
|
|
|
2007-03-17 02:11:45 +03:00
|
|
|
#if OPAL_ENABLE_FT == 1
|
|
|
|
int orte_dss_unpack_ckpt_cmd(orte_buffer_t *buffer, void *dest,
|
|
|
|
orte_std_cntr_t *num_vals, orte_data_type_t type);
|
|
|
|
#endif
|
|
|
|
|
2006-02-07 06:32:36 +03:00
|
|
|
int orte_dss_unpack_data_value(orte_buffer_t *buffer, void *dest,
|
Bring over the ORTE 2.0 DSS. This introduces a few changes, almost all of which are transparent to the user:
1. Introduces a flag for the type of buffer that now allows a user to either have a fully described or a completely non-described buffer. In the latter case, no data type descriptions are included in the buffer. This obviously limits what we can do for debugging purposes, but the intent here was to provide an optimized communications capability for those wanting it.
Note that individual buffers can be designated for either type using the orte_dss.set_buffer_type command. In other words, the buffer type can be set dynamically - it isn't a configuration setting at all. The type will default to fully described. A buffer MUST be empty to set its type - this is checked by the set_buffer_type command, and you will receive an error if you violate that rule.
IMPORTANT NOTE: ORTE 1.x actually will NOT work with non-described buffers. This capability should therefore NOT be used until we tell you it is okay. For now, it is here simply so we can begin bringing over parts of ORTE 2.0. The problem is that ORTE 1.x depends upon the transmission of non-hard-cast data types such as size_t. These "soft" types currently utilize a "peek" function to see their actual type in the buffer - obviously, without description, the system has no idea how to unpack these "soft" types. We will deal with this later - for now, please don't use the non-described buffer option.
2. Introduces the orte_std_cntr_t type. This will become the replacement for the size_t's used throughout ORTE 1.x. At the moment, it is actually typedef'd to size_t for backward compatibility.
3. Introduces the orte_dss.arith API that supports arbitrary arithmetic functions on numeric data types. Calling the function with any other data type will generate an error.
This commit was SVN r11075.
2006-08-01 22:42:25 +04:00
|
|
|
orte_std_cntr_t *num_vals, orte_data_type_t type);
|
2006-02-07 06:32:36 +03:00
|
|
|
|
|
|
|
int orte_dss_unpack_byte_object(orte_buffer_t *buffer, void *dest,
|
Bring over the ORTE 2.0 DSS. This introduces a few changes, almost all of which are transparent to the user:
1. Introduces a flag for the type of buffer that now allows a user to either have a fully described or a completely non-described buffer. In the latter case, no data type descriptions are included in the buffer. This obviously limits what we can do for debugging purposes, but the intent here was to provide an optimized communications capability for those wanting it.
Note that individual buffers can be designated for either type using the orte_dss.set_buffer_type command. In other words, the buffer type can be set dynamically - it isn't a configuration setting at all. The type will default to fully described. A buffer MUST be empty to set its type - this is checked by the set_buffer_type command, and you will receive an error if you violate that rule.
IMPORTANT NOTE: ORTE 1.x actually will NOT work with non-described buffers. This capability should therefore NOT be used until we tell you it is okay. For now, it is here simply so we can begin bringing over parts of ORTE 2.0. The problem is that ORTE 1.x depends upon the transmission of non-hard-cast data types such as size_t. These "soft" types currently utilize a "peek" function to see their actual type in the buffer - obviously, without description, the system has no idea how to unpack these "soft" types. We will deal with this later - for now, please don't use the non-described buffer option.
2. Introduces the orte_std_cntr_t type. This will become the replacement for the size_t's used throughout ORTE 1.x. At the moment, it is actually typedef'd to size_t for backward compatibility.
3. Introduces the orte_dss.arith API that supports arbitrary arithmetic functions on numeric data types. Calling the function with any other data type will generate an error.
This commit was SVN r11075.
2006-08-01 22:42:25 +04:00
|
|
|
orte_std_cntr_t *num_vals, orte_data_type_t type);
|
2006-02-07 06:32:36 +03:00
|
|
|
|
|
|
|
/*
|
|
|
|
* Internal copy functions
|
|
|
|
*/
|
|
|
|
|
|
|
|
int orte_dss_std_copy(void **dest, void *src, orte_data_type_t type);
|
|
|
|
|
|
|
|
int orte_dss_copy_null(char **dest, char *src, orte_data_type_t type);
|
|
|
|
|
|
|
|
int orte_dss_copy_string(char **dest, char *src, orte_data_type_t type);
|
|
|
|
|
|
|
|
int orte_dss_copy_byte_object(orte_byte_object_t **dest, orte_byte_object_t *src,
|
|
|
|
orte_data_type_t type);
|
|
|
|
|
|
|
|
int orte_dss_copy_data_value(orte_data_value_t **dest, orte_data_value_t *src,
|
|
|
|
orte_data_type_t type);
|
|
|
|
/*
|
|
|
|
* Internal compare functions
|
|
|
|
*/
|
|
|
|
|
|
|
|
int orte_dss_compare_bool(bool *value1, bool *value2, orte_data_type_t type);
|
|
|
|
|
|
|
|
int orte_dss_compare_int(int *value1, int *value2, orte_data_type_t type);
|
|
|
|
int orte_dss_compare_uint(uint *value1, uint *value2, orte_data_type_t type);
|
|
|
|
|
|
|
|
int orte_dss_compare_size(size_t *value1, size_t *value2, orte_data_type_t type);
|
|
|
|
|
|
|
|
int orte_dss_compare_pid(pid_t *value1, pid_t *value2, orte_data_type_t type);
|
|
|
|
|
|
|
|
int orte_dss_compare_byte(char *value1, char *value2, orte_data_type_t type);
|
|
|
|
int orte_dss_compare_char(char *value1, char *value2, orte_data_type_t type);
|
|
|
|
int orte_dss_compare_int8(int8_t *value1, int8_t *value2, orte_data_type_t type);
|
|
|
|
int orte_dss_compare_uint8(uint8_t *value1, uint8_t *value2, orte_data_type_t type);
|
|
|
|
|
|
|
|
int orte_dss_compare_int16(int16_t *value1, int16_t *value2, orte_data_type_t type);
|
|
|
|
int orte_dss_compare_uint16(uint16_t *value1, uint16_t *value2, orte_data_type_t type);
|
|
|
|
|
|
|
|
int orte_dss_compare_int32(int32_t *value1, int32_t *value2, orte_data_type_t type);
|
|
|
|
int orte_dss_compare_uint32(uint32_t *value1, uint32_t *value2, orte_data_type_t type);
|
|
|
|
|
|
|
|
int orte_dss_compare_int64(int64_t *value1, int64_t *value2, orte_data_type_t type);
|
|
|
|
int orte_dss_compare_uint64(uint64_t *value1, uint64_t *value2, orte_data_type_t type);
|
|
|
|
|
|
|
|
int orte_dss_compare_null(char *value1, char *value2, orte_data_type_t type);
|
|
|
|
|
|
|
|
int orte_dss_compare_string(char *value1, char *value2, orte_data_type_t type);
|
|
|
|
|
Bring over the ORTE 2.0 DSS. This introduces a few changes, almost all of which are transparent to the user:
1. Introduces a flag for the type of buffer that now allows a user to either have a fully described or a completely non-described buffer. In the latter case, no data type descriptions are included in the buffer. This obviously limits what we can do for debugging purposes, but the intent here was to provide an optimized communications capability for those wanting it.
Note that individual buffers can be designated for either type using the orte_dss.set_buffer_type command. In other words, the buffer type can be set dynamically - it isn't a configuration setting at all. The type will default to fully described. A buffer MUST be empty to set its type - this is checked by the set_buffer_type command, and you will receive an error if you violate that rule.
IMPORTANT NOTE: ORTE 1.x actually will NOT work with non-described buffers. This capability should therefore NOT be used until we tell you it is okay. For now, it is here simply so we can begin bringing over parts of ORTE 2.0. The problem is that ORTE 1.x depends upon the transmission of non-hard-cast data types such as size_t. These "soft" types currently utilize a "peek" function to see their actual type in the buffer - obviously, without description, the system has no idea how to unpack these "soft" types. We will deal with this later - for now, please don't use the non-described buffer option.
2. Introduces the orte_std_cntr_t type. This will become the replacement for the size_t's used throughout ORTE 1.x. At the moment, it is actually typedef'd to size_t for backward compatibility.
3. Introduces the orte_dss.arith API that supports arbitrary arithmetic functions on numeric data types. Calling the function with any other data type will generate an error.
This commit was SVN r11075.
2006-08-01 22:42:25 +04:00
|
|
|
int orte_dss_compare_std_cntr(orte_std_cntr_t *value1, orte_std_cntr_t *value2, orte_data_type_t type);
|
|
|
|
|
2006-02-07 06:32:36 +03:00
|
|
|
int orte_dss_compare_dt(orte_data_type_t *value1, orte_data_type_t *value2, orte_data_type_t type);
|
|
|
|
|
2007-03-17 02:11:45 +03:00
|
|
|
#if OPAL_ENABLE_FT == 1
|
|
|
|
int orte_dss_compare_ckpt_cmd(size_t *value1, size_t *value2, orte_data_type_t type);
|
|
|
|
#endif
|
|
|
|
|
2006-02-07 06:32:36 +03:00
|
|
|
int orte_dss_compare_data_value(orte_data_value_t *value1, orte_data_value_t *value2, orte_data_type_t type);
|
|
|
|
|
|
|
|
int orte_dss_compare_byte_object(orte_byte_object_t *value1, orte_byte_object_t *value2, orte_data_type_t type);
|
|
|
|
|
|
|
|
/*
|
|
|
|
* Internal size functions
|
|
|
|
*/
|
|
|
|
int orte_dss_std_size(size_t *size, void *src, orte_data_type_t type);
|
|
|
|
|
|
|
|
int orte_dss_size_string(size_t *size, char *src, orte_data_type_t type);
|
|
|
|
|
|
|
|
int orte_dss_size_data_value(size_t *size, orte_data_value_t *src, orte_data_type_t type);
|
|
|
|
|
|
|
|
int orte_dss_size_byte_object(size_t *size, orte_byte_object_t *src, orte_data_type_t type);
|
|
|
|
|
|
|
|
/*
|
|
|
|
* Internal print functions
|
|
|
|
*/
|
|
|
|
int orte_dss_print_byte(char **output, char *prefix, uint8_t *src, orte_data_type_t type);
|
|
|
|
|
|
|
|
int orte_dss_print_string(char **output, char *prefix, char *src, orte_data_type_t type);
|
|
|
|
|
|
|
|
int orte_dss_print_size(char **output, char *prefix, size_t *src, orte_data_type_t type);
|
|
|
|
int orte_dss_print_pid(char **output, char *prefix, pid_t *src, orte_data_type_t type);
|
|
|
|
int orte_dss_print_bool(char **output, char *prefix, bool *src, orte_data_type_t type);
|
|
|
|
int orte_dss_print_int(char **output, char *prefix, int *src, orte_data_type_t type);
|
|
|
|
int orte_dss_print_uint(char **output, char *prefix, int *src, orte_data_type_t type);
|
|
|
|
int orte_dss_print_uint8(char **output, char *prefix, uint8_t *src, orte_data_type_t type);
|
|
|
|
int orte_dss_print_uint16(char **output, char *prefix, uint16_t *src, orte_data_type_t type);
|
|
|
|
int orte_dss_print_uint32(char **output, char *prefix, uint32_t *src, orte_data_type_t type);
|
|
|
|
int orte_dss_print_int8(char **output, char *prefix, int8_t *src, orte_data_type_t type);
|
|
|
|
int orte_dss_print_int16(char **output, char *prefix, int16_t *src, orte_data_type_t type);
|
|
|
|
int orte_dss_print_int32(char **output, char *prefix, int32_t *src, orte_data_type_t type);
|
|
|
|
#ifdef HAVE_INT64_T
|
|
|
|
int orte_dss_print_uint64(char **output, char *prefix, uint64_t *src, orte_data_type_t type);
|
|
|
|
int orte_dss_print_int64(char **output, char *prefix, int64_t *src, orte_data_type_t type);
|
|
|
|
#else
|
|
|
|
int orte_dss_print_uint64(char **output, char *prefix, void *src, orte_data_type_t type);
|
|
|
|
int orte_dss_print_int64(char **output, char *prefix, void *src, orte_data_type_t type);
|
|
|
|
#endif
|
|
|
|
int orte_dss_print_null(char **output, char *prefix, void *src, orte_data_type_t type);
|
Bring over the ORTE 2.0 DSS. This introduces a few changes, almost all of which are transparent to the user:
1. Introduces a flag for the type of buffer that now allows a user to either have a fully described or a completely non-described buffer. In the latter case, no data type descriptions are included in the buffer. This obviously limits what we can do for debugging purposes, but the intent here was to provide an optimized communications capability for those wanting it.
Note that individual buffers can be designated for either type using the orte_dss.set_buffer_type command. In other words, the buffer type can be set dynamically - it isn't a configuration setting at all. The type will default to fully described. A buffer MUST be empty to set its type - this is checked by the set_buffer_type command, and you will receive an error if you violate that rule.
IMPORTANT NOTE: ORTE 1.x actually will NOT work with non-described buffers. This capability should therefore NOT be used until we tell you it is okay. For now, it is here simply so we can begin bringing over parts of ORTE 2.0. The problem is that ORTE 1.x depends upon the transmission of non-hard-cast data types such as size_t. These "soft" types currently utilize a "peek" function to see their actual type in the buffer - obviously, without description, the system has no idea how to unpack these "soft" types. We will deal with this later - for now, please don't use the non-described buffer option.
2. Introduces the orte_std_cntr_t type. This will become the replacement for the size_t's used throughout ORTE 1.x. At the moment, it is actually typedef'd to size_t for backward compatibility.
3. Introduces the orte_dss.arith API that supports arbitrary arithmetic functions on numeric data types. Calling the function with any other data type will generate an error.
This commit was SVN r11075.
2006-08-01 22:42:25 +04:00
|
|
|
int orte_dss_print_std_cntr(char **output, char *prefix, orte_std_cntr_t *src, orte_data_type_t type);
|
2006-02-07 06:32:36 +03:00
|
|
|
int orte_dss_print_data_type(char **output, char *prefix, orte_data_type_t *src, orte_data_type_t type);
|
2007-03-17 02:11:45 +03:00
|
|
|
#if OPAL_ENABLE_FT == 1
|
|
|
|
int orte_dss_print_ckpt_cmd(char **output, char *prefix, size_t *src, orte_data_type_t type);
|
|
|
|
#endif
|
2006-02-07 06:32:36 +03:00
|
|
|
int orte_dss_print_data_value(char **output, char *prefix, orte_data_value_t *src, orte_data_type_t type);
|
|
|
|
int orte_dss_print_byte_object(char **output, char *prefix, orte_byte_object_t *src, orte_data_type_t type);
|
|
|
|
|
|
|
|
|
|
|
|
/*
|
|
|
|
* Internal release functions
|
|
|
|
*/
|
|
|
|
void orte_dss_std_release(orte_data_value_t *value);
|
|
|
|
|
|
|
|
void orte_dss_std_obj_release(orte_data_value_t *value);
|
|
|
|
|
|
|
|
void orte_dss_release_byte_object(orte_data_value_t *value);
|
|
|
|
|
|
|
|
/*
|
|
|
|
* Internal helper functions
|
|
|
|
*/
|
|
|
|
|
|
|
|
char* orte_dss_buffer_extend(orte_buffer_t *bptr, size_t bytes_to_add);
|
|
|
|
|
|
|
|
bool orte_dss_too_small(orte_buffer_t *buffer, size_t bytes_reqd);
|
|
|
|
|
Bring over the ORTE 2.0 DSS. This introduces a few changes, almost all of which are transparent to the user:
1. Introduces a flag for the type of buffer that now allows a user to either have a fully described or a completely non-described buffer. In the latter case, no data type descriptions are included in the buffer. This obviously limits what we can do for debugging purposes, but the intent here was to provide an optimized communications capability for those wanting it.
Note that individual buffers can be designated for either type using the orte_dss.set_buffer_type command. In other words, the buffer type can be set dynamically - it isn't a configuration setting at all. The type will default to fully described. A buffer MUST be empty to set its type - this is checked by the set_buffer_type command, and you will receive an error if you violate that rule.
IMPORTANT NOTE: ORTE 1.x actually will NOT work with non-described buffers. This capability should therefore NOT be used until we tell you it is okay. For now, it is here simply so we can begin bringing over parts of ORTE 2.0. The problem is that ORTE 1.x depends upon the transmission of non-hard-cast data types such as size_t. These "soft" types currently utilize a "peek" function to see their actual type in the buffer - obviously, without description, the system has no idea how to unpack these "soft" types. We will deal with this later - for now, please don't use the non-described buffer option.
2. Introduces the orte_std_cntr_t type. This will become the replacement for the size_t's used throughout ORTE 1.x. At the moment, it is actually typedef'd to size_t for backward compatibility.
3. Introduces the orte_dss.arith API that supports arbitrary arithmetic functions on numeric data types. Calling the function with any other data type will generate an error.
This commit was SVN r11075.
2006-08-01 22:42:25 +04:00
|
|
|
orte_dss_type_info_t* orte_dss_find_type(orte_data_type_t type);
|
|
|
|
|
2006-02-07 06:32:36 +03:00
|
|
|
int orte_dss_store_data_type(orte_buffer_t *buffer, orte_data_type_t type);
|
|
|
|
|
|
|
|
int orte_dss_get_data_type(orte_buffer_t *buffer, orte_data_type_t *type);
|
|
|
|
|
|
|
|
#if defined(c_plusplus) || defined(__cplusplus)
|
|
|
|
}
|
|
|
|
#endif
|
|
|
|
#endif
|