Run client handler functions in separate thread #165
Merged
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
jhurliman
reviewed
Feb 16, 2023
| : logTime(logTime) | ||
| , publishTime(publishTime) | ||
| , sequence(sequence) | ||
| , advertisement(advertisement) | ||
| , dataLength(dataLength) | ||
| , data(data) {} | ||
| , data(dataLength) { | ||
| std::memcpy(data.data(), rawData, dataLength); |
There was a problem hiding this comment.
Is the additional copy worth it? We should test on a low-power platform like a Jetson Nano.
There was a problem hiding this comment.
We have to do a copy now since we call the handler in a different thread and the pointer to the original data is likely not valid anymore.
jhurliman
reviewed
Feb 16, 2023
|
|
||
| ClientMessage(uint64_t logTime, uint64_t publishTime, uint32_t sequence, | ||
| const ClientAdvertisement& advertisement, size_t dataLength, const uint8_t* data) | ||
| const ClientAdvertisement& advertisement, size_t dataLength, const uint8_t* rawData) | ||
| : logTime(logTime) | ||
| , publishTime(publishTime) | ||
| , sequence(sequence) | ||
| , advertisement(advertisement) |
There was a problem hiding this comment.
This is now a copy, but I'm assuming ClientAdvertisement is relatively cheap to copy?
There was a problem hiding this comment.
Yes I think so too. At this stage I would rather have an extra copy then some hard to find bug. But yes, there is definitely potential for improvement later on
jhurliman
approved these changes
Feb 17, 2023
Base automatically changed from
achim/decouple_server_implementation
to
main
February 17, 2023 18:10
achim-k
force-pushed
the
achim/client_handlers_separate_thread
branch
from
82c53b3
to
4d512fe
Compare
achim-k
added a commit
that referenced
this pull request
Apr 28, 2023
…210) ### Public-Facing Changes None ### Description - Refactors the way handler functions are run in a separate thread. It's better to do that in a unified way in the server rather than doing that for ROS 1 & 2 differently as it was implemented in #165 - Catch exeptions thrown in handler functions and send status message to client Fixes #148
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
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.
Public-Facing Changes
Description
Builds on top of #156
So far we have executed client handler functions in the websocket server thread. This could cause issues with clients not receiving messages anymore while a longer-running handler function was executing. This PR fixes this by handler functions being executed in a separate thread.
Fixes #164
Fixes FG-2029