Fix threads never closing. #542
Merged
Conversation
This file contains hidden or 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
The threads where never actually exited since they would hang waiting for next message in the queue for ever. To fix this we send a None message to unlock the queue. The _should_close flag (was created but not used before) should be used to actually close the thread
The param callback modifyed the original packet. The owner of the packet is not the param thread but the caller, and its better not to modify it. The caller might call several callbacks after and they should get the original
gemenerik
approved these changes
Jun 5, 2025
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.
There where some threads (param related) that would never close.
They would even keep their Crazyflie object alive forever. This would slow down performance over time.
Fix this by making sure the threads exit by sending a None object to the queue and setting the should_close flag.
Previously we where counting on this behavior and never created new thread objects upon reconnect of the same crazyflie object. So I added creation of the thread objects if there is no object (i.e the connection was closed).
This way you can re-use the same Crazyflie object if you want (this is done in testing), or throw it away and create a new object. Both of these will create the correct number of threads.
Did some cleanup by naming the threads for easier debugging. I also made sure the callbacks in param.py does not modify the original message. This could cause unknown side effects.