We read every piece of feedback, and take your input very seriously.
To see all available qualifiers, see our documentation.
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
This is related to but different from #166 : The opcua-server api expects the user to wrap their getters and setters in an std::sync::Mutex (https://docs.rs/opcua-server/0.8.1/opcua_server/address_space/variable/struct.Variable.html#method.set_value_setter), which means that two clients accessing the same variable at the same time will lock the entire tokio executor. Is their a reason to have a synchonous instead of an asynchronous mutex here ?
std::sync::Mutex
The text was updated successfully, but these errors were encountered:
No branches or pull requests
This is related to but different from #166 : The opcua-server api expects the user to wrap their getters and setters in an
std::sync::Mutex
(https://docs.rs/opcua-server/0.8.1/opcua_server/address_space/variable/struct.Variable.html#method.set_value_setter), which means that two clients accessing the same variable at the same time will lock the entire tokio executor. Is their a reason to have a synchonous instead of an asynchronous mutex here ?The text was updated successfully, but these errors were encountered: