-
-
Notifications
You must be signed in to change notification settings - Fork 3.6k
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
[chromecast] Initialize connection to devices asynchronously #9228
[chromecast] Initialize connection to devices asynchronously #9228
Conversation
scheduler.submit(() -> { | ||
// initialize connection to devices asynchronously | ||
Coordinator localCoordinator = coordinator; | ||
if (localCoordinator != null && (!localCoordinator.chromeCast.getAddress().equals(ipAddress) | ||
|| localCoordinator.chromeCast.getPort() != config.port)) { | ||
localCoordinator.destroy(); | ||
localCoordinator = coordinator = null; | ||
} | ||
|
||
if (localCoordinator == null) { | ||
ChromeCast chromecast = new ChromeCast(ipAddress, config.port); | ||
localCoordinator = new Coordinator(this, thing, chromecast, config.refreshRate, audioHTTPServer, | ||
callbackUrl); | ||
localCoordinator.initialize(); | ||
coordinator = localCoordinator; | ||
} | ||
}); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I think quickly cycling the handler (initialize->dispose->initialize) would cause multiple Coordinator instances to be created simultaneously and also lose track of one of them.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Okay. Calling the coordinator.initialize()
method asynchronously and keep the instance creating like before should work either.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Only if coordinator.initialize()
is synchronized along with coordinator.destroy()
as well as adding an early exit in coordinator.initialize()
if coordinator.destroy()
was called first.
I think that would make it thread safe.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@cweitkamp Do you have this PR still on your radar?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@kaikreuzer Thanks for the reminder. I updated the PR with the suggested solution above.
Signed-off-by: Christoph Weitkamp <[email protected]>
980e97e
to
d629b55
Compare
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Thanks, lgtm.
Signed-off-by: Christoph Weitkamp <[email protected]> Signed-off-by: John Marshall <[email protected]>
Signed-off-by: Christoph Weitkamp <[email protected]>
Signed-off-by: Christoph Weitkamp <[email protected]>
Signed-off-by: Christoph Weitkamp <[email protected]>
Signed-off-by: Christoph Weitkamp [email protected]