DDS 1.2 RTF Avatar
  1. OMG Issue

DDS12 — String sequence should be a parameter and not return value

  • Key: DDS12-72
  • Legacy Issue Number: 9555
  • Status: closed  
  • Source: Real-Time Innovations ( Dr. Gerardo Pardo-Castellote, Ph.D.)
  • Summary:

    Summary:

    In Section 2.1.2.5.2.11 (notify_datareaders) the first sentence states
    This operation invokes the operation on_data_available on the DataReaderListener objects attached to contained DataReader entities containing samples with SampleState 'NOT_READ' and any ViewState and InstanceState.
    In Section 2.1.4.2.2 (Changes in Read Communication Statuses) it states in the first paragraph that the "StatusChangedFlag becomes false again when all samples are removed from the responsibility of the middleware via the take operation on the proper DataReader entities".
    In Figure 2-16 in the same section, the transition from the TRUE state to FALSE is accompanied by the condition "DataReader:take[all data taken by application]".

    However, in Section 2.1.4.4 (Condition and Wait-sets) in the last step in the general use pattern deals with using the result of the wait operation and in the third sub-bullet it states how if the wait unblocked due to a StatusCondition and the status change is DATA_AVAILABLE, the appropriate action is to call read/take on the relevant DataReader.
    If only a take of all samples will reset the status, then simply calling read in this use pattern will not reset the status and the given general use pattern will actual spin.

    Proposed Resolution:

    The actual condition for the StatusChangedFlag to become false should then be that the status has been considered read/accessed by the user. This should be considered as such when the listener for a Read Communication Status is called similar to Plain Communication Statuses (see T#6).
    In addition, it should be such if the user calls read/take on the associated DataReader.

    Subscriber's DATA_ON_READERS status is reset if the on_data_on_readers is called (same as for all listeners).

    In addition Subscriber's DATA_ON_READERS status is reset if the user calls read or take on any of the DataReaders belonging to the Subscriber.
    In addition, the Subscriber's DATA_ON_READERS status is also reset if the on_data_available callback is called on the DataReaderListener. This is needed such that if the application calls notify_datareaders it will reset the status.
    The inverse, i.e. resetting the DATA_AVAILABLE status when the on_data_on_readers callback is called) does not happen.

    Proposed Revised Text:

    Section 2.1.2.5.2.11 notify_datareaders

    In the first sentence, change

    DataReader entities containing samples with SampleState 'NOT_READ' and any ViewState and InstanceState

    To

    DataReader entities with a DATA_AVAILABLE status that is considered changed.

    Section 2.1.4.2.2 Changes in Read Communication Statuses

    Change the last sentence of the first paragraph from
    The StatusChangedFlag becomes false again when all the samples are removed from the responsibility of the middleware via the take operation on the proper DataReader entitites.

    To

    The DATA_AVAILABLE StatusChangedFlag becomes false again when either the corresponding listener operation (on_data_available ) is called or a read or take operation is called on the associated DataReader.

    The DATA_ON_READERS StatusChangedFlag becomes false again when any of the following occurs:

    o The corresponding listener operation (on_data_on_readers) is called.
    o The on_data_available listener operation is called on any DataReader belonging to the Subscriber.
    o The read or take on any DataReader belonging to the Subscriber

    In Figure 2-16

    Introduce two figures one for the DATA_ON_READERS and the other for the DATA_AVAILABLE

  • Reported: DDS 1.1 — Thu, 6 Apr 2006 04:00 GMT
  • Disposition: Resolved — DDS 1.2
  • Disposition Summary:

    see above

  • Updated: Fri, 6 Mar 2015 20:58 GMT