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

Fix deadlock when updating camera & renderer properties via Rockets #569

Merged
merged 3 commits into from
Sep 21, 2018

Conversation

tribal-tec
Copy link
Contributor

Due the data race fixes in the latest Rockets versions, it revealed this wrong
behavior in Brayns, where the updates on property objects from within Rockets
shall not trigger the onModified() callback which would lead to an
unnecessary (and deadlocking) notification.

@tribal-tec tribal-tec requested a review from hernando September 19, 2018 15:13
Copy link
Contributor

@rolandjitsu rolandjitsu left a comment

Choose a reason for hiding this comment

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

Just tested, looks OK.

@@ -1214,7 +1218,7 @@ class RocketsPlugin::Impl
PropertyMap props = object.getPropertyMap();
if (::from_json(props, request.message))
{
object.updateProperties(props);
object.updateProperties(props, false);
Copy link
Contributor

Choose a reason for hiding this comment

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

Is it OK to not update the UI if you make changes from a notebook? Or does the rebroadcast at the bottom solve that problem?

Copy link
Contributor

Choose a reason for hiding this comment

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

Try it out :)

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Yes, the rebroadcast solves that. The callback triggered by markModified() is needed for 'internal' and plugin changes.

@tribal-tec
Copy link
Contributor Author

I'll fix this differently, hang tight and hold on.

@tribal-tec
Copy link
Contributor Author

Updated. Please review again.

@tribal-tec tribal-tec requested a review from rdumusc September 21, 2018 09:13
uintptr_t* _currentClientID;
};

void bindEndpoint(const std::string& method,
Copy link
Contributor

Choose a reason for hiding this comment

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

No leading _?

@@ -1254,6 +1328,9 @@ class RocketsPlugin::Impl
std::unordered_map<std::string, std::pair<std::mutex, Throttle>> _throttle;
std::vector<std::function<void()>> _delayedNotifies;
std::mutex _delayedNotifiesMutex;
static constexpr uintptr_t NO_CURRENT_CLIENT{
std::numeric_limits<uintptr_t>::max()};
Copy link
Contributor

Choose a reason for hiding this comment

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

If this is representing an opaque pointer, you can also use 0 for brevity.

}

template <typename Params>
void _connectEndpoint(const std::string& method,
Copy link
Contributor

Choose a reason for hiding this comment

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

Why these methods are not called bind as well? Because they return OK?

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Because in rockets they are called connect as well.

Due the data race fixes in the latest Rockets versions, it revealed this wrong
behavior in Brayns, where the updates on property objects from within Rockets
shall not trigger the onModified() callback which would lead to an
unnecessary (and deadlocking) notification.
@tribal-tec tribal-tec merged commit 641457f into BlueBrain:master Sep 21, 2018
@tribal-tec tribal-tec added the bug label Sep 26, 2018
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants