DDS12 — read/take_next_instance()

Must read/take_next_instance() require that the handle corresponds to a known data-object?

Summary:

In sections for read/take_next_instance() and read/take_next_instance_w_condition() it states that if detectable the implementation should return BAD_PARAMETER in this case or otherwise the situation is unspecified.
It might be desirable to allow for an invalid handle to be passed in, especially in the case that the user is iterating through instances and takes all samples to an instance that is NOT_ALIVE and has no writers in which case that action may actually free that instance, "invalidating" the handle of that instance.

Proposed Resolution:

Allow passing a handle that does not correspond to any instance currently on the DataReader to read_next_instance/take_next_instance. This handle should be sorted in a deterministic way with regards to the other handles such that the iteration is not interrupted.
Proposed Revised Text:

Section 2.1.2.5.3.16 read_next_instance

Replace the paragraph:

This operation implies the existence of some total order 'greater than' relationship between the instance handles. The specifics of this relationship are not important and are implementation specific. The important thing is that, according to the middleware, all instances are ordered relative to each other. This ordering is between the instances, that is, it does not depend on the actual samples received or available. For the purposes of this explanation it is 'as if' each instance handle was represented as a unique integer.

With:

This operation implies the existence of a total order 'greater-than' relationship between the instance handles. The specifics of this relationship are not all important and are implementation specific. The important thing is that, according to the middleware, all instances are ordered relative to each other. This ordering is between the instance handles: It should not depend on the state of the instance (e.g. whether it has data or not) and must be defined even for instance handles that do not correspond to instances currently managed by the DataReader. For the purposes of the ordering it should be 'as if' each instance handle was represented as a unique integer.

Section 2.1.2.5.3.16 read_next_instance

Remove the paragraph:

The behavior of the read_instance operation follows the same rules as the read operation regarding the pre-conditions and post-conditions for the data_values and sample_infos collections. Similar to read, the read_instance operation may 'loan' elements to the output collections which must then be returned by means of return_loan.

Replace the paragraph:

This operation may return BAD_PARAMETER if the InstanceHandle_t a_handle does not correspond to an existing data-object known to the DataReader. If the implementation is not able to check invalid handles, then the result in this situation is unspecified.

With

Note that it is possible to call the 'read_next_instance' operation with an instance handle that does not correspond to an instance currently managed by the DataReader. This is because as stated earlier the 'greater-than' relationship is defined even for handles not managed by the DataReader. One practical situation where this may occur is when an applications is iterating though all the instances, takes all the samples of a NOT_ALIVE_NO_WRITERS instance, returns the loan (at which point the instance information may be removed, and thus the handle becomes invalid), and tries to read the next instance.

Section 2.1.2.5.3.17 take_next_instance

Replace the paragraph:

This operation may return BAD_PARAMETER if the InstanceHandle_t a_handle does not correspond to an existing data-object known to the DataReader. If the implementation is not able to check invalid handles, then the result in this situation is unspecified.

With

Similar to the operation read_next_instance (see Section 2.1.2.5.3.16) it is possible to call take_next_instance with an instance handle that does not correspond to an instance currently managed by the DataReader.

Section 2.1.2.5.3.18 read_next_instance_w_condition

Replace the paragraph:

This operation may return BAD_PARAMETER if the InstanceHandle_t a_handle does not correspond to an existing data-object known to the DataReader. If the implementation is not able to check invalid handles, then the result in this situation is unspecified.

With

Similar to the operation read_next_instance (see Section 2.1.2.5.3.16) it is possible to call read_next_instance with an instance handle that does not correspond to an instance currently managed by the DataReader.

Section 2.1.2.5.3.19 take_next_instance_w_condition
Replace the paragraph:

This operation may return BAD_PARAMETER if the InstanceHandle_t a_handle does not correspond to an existing data-object known to the DataReader. If the implementation is not able to check invalid handles, then the result in this situation is unspecified.

With

Similar to the operation read_next_instance (see Section 2.1.2.5.3.16) it is possible to call take_next_instance_w_condition with an instance handle that does not correspond to an instance currently managed by the DataReader.

see above