Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

[core/IPCChannel] : Unregister the handlers in the full chain. #1697

Closed
wants to merge 24 commits into from

Conversation

msieben
Copy link
Contributor

@msieben msieben commented Jul 18, 2024

Handlers are registerd via the client in the 'Accept' method but are 'forgotten' via the 'Cleanup' if already being explicitly unregistered.

@msieben msieben marked this pull request as ready for review July 18, 2024 11:22
@@ -333,6 +333,11 @@ namespace Core {
ASSERT(index != _handlers.end());

if (index != _handlers.end()) {
for(auto it = _clients.begin(), tail = _clients.end(); it != tail; it++) {
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This is making the Register/Unregister a-symetrical. The Register records the offered interface, the Unregister should remove it (Symetrical) but now it also starts to Unregister something else? What does this resolve ? I guess the use case might be missing something..

Copy link
Contributor Author

@msieben msieben Aug 19, 2024

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

As communicated, the use case is shown in another branch / open PR. You might have forgotten about it: #1698. It also contains some explanation.

Copy link
Contributor Author

@msieben msieben Aug 19, 2024

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

You might also have a look at the description in https://jira.rdkcentral.com/jira/browse/METROL-1024.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@msieben Question is if the a-symetrical part (The unregister also now unregisters some Client stuff) should not have been done long before the handler is unregistered and thus the issue should be resolved somewhere else to make the test case succeed. It could be that Clients might still exists at the moment this destructor runs. Than the Clients must be closed before the IPCChannel is destructed.. So could well be an issue but should the unregstering of the client not have happened before the Handlers get unregistered....

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@pwielders I believe your suggested flow is not really apparent from the interface description. Synchronisation has been in place, and, scoping the client has not shown additional improvements. However, reordering the server side flow has. Especially, Cleanup prior Unregister - server side -, apparently is needed to avoid issues, which imho is confusing. Pushed changes.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@msieben msieben requested a review from pwielders August 21, 2024 07:43
@msieben
Copy link
Contributor Author

msieben commented Sep 16, 2024

Superseded by #1698

@msieben msieben closed this Sep 16, 2024
@pwielders pwielders deleted the development/ipcchannel_dangling_handlers branch October 11, 2024 18:27
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants