-
Notifications
You must be signed in to change notification settings - Fork 357
Commit
This commit does not belong to any branch on this repository, and may belong to a fork outside of the repository.
Implement delayed enabling of entities using dds_enable()
Signed-off-by: TheFixer <thefixer@iteazz.com> This pull request implements delayed enabling of entities, in particular of publishers, subscribers, readers and writers. Delayed enabling allows immutable qos changes to be changed as long as the entity is not enabled, but once the entity is enabled immutable qos changes are not allowed anymore. Delayed enabling is implemented by deferring the creation of ddsi entities as long as the entity is not enabled. The application can call dds_enable() on a disabled entity to enable it. Calling dds_enable() on an already enabled entity is considered a noop for the application. This pull request implements the following behaviour: - Participants are always enabled. - Created entities will be automatically enabled when their parent entity is enabled, and their parent has autoenable set to true. This is the default. - Calling dds_create_writer() on a disabled publisher which has autoenable=true will return a dds writer without a corresponding ddsi writer (and similar for readers) - Disabled entities can be enabled by calling dds_enable() on the entity. When the parent of the entity is not enabled, enabling will fail and return with DDS_RETCODE_PRECONDITION_NOT_MET. When the entity cannot be enabled because of qos mismatches or invalid security credentials, an error code will be returned. The call dds_enable() will return DDS_RETCODE_OK if is has enabled the entity and alls its disabled children that have been created while their parent has autoenable=true. If not all children are successfully enabled then dds_enable() will return with the error code of the first child that that could not be enabled. - Calling dds_enable() on an already enabled entity is a noop. - The m_iid is pre-allocated when a dds_entity is created, and is reused when the corresponding ddsi entity gets enabled. - Immutable QoS settings can be changed on an entity as long as the entity is not enabled. As a consequence the creation of some qos dependent structures (like whc) have been moved from the dds entity to the ddsi entity. - The whc is created when entity is enabled, not prior to that. The same holds for the xpack creation. - When readers that have no predefined rhc, the rhc will be created when the reader gets enabled (i.e., the call to dds_rhc_default_new() is done when the entity is enabled) - Readers that do have a predefined rhc will use this rhc when becoming enabled. - thread_state_awake() and thread_state_sleep() functions have moved to the location where entities are enabled. - The check for the availability of the security credentials has been moved to location where entities are enabled. This implies that a disabled dds writer or reader can be created before checking its security credentials. To not change legacy behaviour the creation of a dds reader or writer fails with DDS_RETCODE_NOT_ALLOWED_BY_SECURITY when the reader or writer is automatically enabled when created. Note that this can only happen for writers whose parent is enabled and have autoenabled set to true. - If an entity (e.g., subscriber) is enabled which causes recursive calls to dds_enable() on multiple children (e.g., readers), and some of these child entities are successfully enabled and others are not (e.g., because the some of the readers have the correct security credentials and others have not) then the dds_enable() on the parent will fail. It is the responsibility of the application to find out which of the entities have been enabled, and which have not. - When a reader is created with an implicit subscriber, then the implicit subscriber is enabled if and only if the autoenable setting of the participant is set to true. Similarly for the creation of a writer with an implicit publisher. - Various tests have been implemented. Notes for the reviewer. - If a participant has autoenable=false and an reader (or writer) with an implicit subscriber (or publisher) is created, I don't think it is possible to enable the implicit subscriber (or publisher)( anymore. I therefore think it would be wise to prevent the creation of a reader (or writer) with an implicit subscriber (or publisher) when the participant has autoenable=false, and return DDS_RETCODE_PRECONDITION_NOT_MET in that case. Do you agree? - Currently, I don't use locking when recursively enabling children. Please check. - I am not sure, but I have the impression that some security tests take much time. Not sure if it is caused by this pull request.
- Loading branch information
Showing
26 changed files
with
1,808 additions
and
216 deletions.
There are no files selected for viewing
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Oops, something went wrong.