DDS12 — Resetting of the statusflag during a listener callback

Summary:
In section 2.1.4.2.1, it is explained that a statusflag becomes TRUE if a plain communication status changes, and becomes FALSE again each time the application accesses the plain communication status via the proper get_<plain_communication_status> operation. This is not a complete description, since it only assumes an explicit call to read the communication status. It is also possible (by attaching a Listener) to implicitly read the status (it is then passed as a parameter to the registered callback method), and then afterwards the status flag should also be set to FALSE as well.
Furthermore, the Status table in section 2.4.1 mentions that all total_count_change fields are being reset when a Listener callback is performed. The same thing happens when a get_<plain_communication_status> operation is invoked. It would make sense that a Listener callback behaves in a similar way as an when explicitly reading the plain communication status.

Proposed Resolution::
Mention explicitly in section 2.1.4.2.1 that a status flag is also set to FALSE when a listener callback for that status has been performed. (We need to think what consequences this will have for NIL-Listeners, that behave like a no-op. Probably they should also reset the flag in that case.)

Proposed Revised Text::

In section 2.1.4.2.1 after the paragraph:
For the plain communication status, the StatusChangedFlag flag is initially set to FALSE. It becomes TRUE whenever the plain communication status changes and it is reset to FALSE each time the application accesses the plain communication status via the proper get_<plain communication status> operation on the Entity.

Add the paragraphs:

The communication status is also reset to FALSE whenever the associated listener operation is called as the listener implicitly accesses the status which is passed as a parameter to the operation. The fact that the status is reset prior to calling the listener means that if the application calls the get_<plain communication status> from inside the listener it will see the status already reset.

An exception to this rule is when the associated listener is the 'nil' listener. As described in section 2.1.4.3.1 the 'nil' listener is treaded as a NOOP and the act of calling the 'nil' listener does not reset the communication status.

see above