Okay, I've traced this down. The problem is that a DSS-internal function has
been exposed via the API, so now people can mistakenly call the wrong one.
You should -never- be using opal_dss.pack_buffer or opal_dss.unpack_buffer.
Those were supposed to be internal to the DSS only, and will definitely
WOW! Somebody really screwed up the DSS by adding some new API's I'd never
heard of before, but really can cause the system to break!
I'm going to have to straighten this mess out - it is a total disaster.
There needs to be just ONE way of packing and unpacking, not two totally
incompatible method
Hi Ralph,
Mi mistake, I'm really using ORTE_PROC_MY_DAEMON->jobid.
I have success using pack_buffer()/unpack_buffer() and OPAL_BYTE type,
something strange occur when I was using pack()/unpack(). The value of
num_bytes increase, example:
I tried to read num_bytes=5, and after a unpack this var
On 6/17/08 3:35 PM, "Leonardo Fialho" wrote:
> Hi Ralph,
>
> 1) Yes, I'm using ORTE_RML_TAG_DAEMON with a new "command" that I
> defined in "odls_types.h".
> 2) I'm packing and unpacking variables like OPAL_INT, OPAL_SIZE, ...
> 3) I'm not blocking the "process_commands" function with long co
Hi Ralph,
1) Yes, I'm using ORTE_RML_TAG_DAEMON with a new "command" that I
defined in "odls_types.h".
2) I'm packing and unpacking variables like OPAL_INT, OPAL_SIZE, ...
3) I'm not blocking the "process_commands" function with long code.
4) To know the daemon's vpid and jobid I used the same
I'm not sure exactly how you are trying to do this, but the usual procedure
would be:
1. call opal_dss.pack(*buffer, *data, #data, data_type) for each thing you
want to put in the buffer. So you might call this to pack a string:
opal_dss.pack(*buffer, &string, 1, OPAL_STRING);
2. once you have e
Hi All,
I´m using RML to send log messages from a PML to a ORTE daemon (located
in another node). I got success sending the message header, but now I
need to send the message data (buffer). How can I do it? The problem is
what data type I need to use for packing/unpacking? I tried
OPAL_DATA_V
