add mechanism to unblock dsgsessioon poll messages method when a PyEnSight gRPC request is incoming #505
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
A few months ago Randy put in place a check in the DSGSession poll_messages method that avoids putting too many gRPC requests in the DSG queue.
This fixed an issue with Omniverse when large data with many DSG messages are being considered, but opened a new issue in case the DSG session is running in the same process with a PyEnSight session
PyEnSight has no knowledge that the poll_messages is idle, and when you send a new gRPC request through PyEnSight, the gRPC connection deadlocks
This PR fixes the issue, allowing to register a running DSGSession to a PyEnSight session, either directly or when creating the DSGSession, passing in as optional argument the PyEnSight session itself
In session.cmd, before sending the actual gRPC command, a flag is set to True so that if the DSGSession poll_message is idle, it will be temporarily unblocked, for the time the gRPC command runs on PyEnSight. This can allow temporarily the message queue in DSG to overcome the limit, but the flag is set back to False so that poll_messages gets idle again