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

Sync classes do not handle lost connection in a good way #366

Closed
krichardsson opened this issue Dec 1, 2022 · 0 comments · Fixed by #367
Closed

Sync classes do not handle lost connection in a good way #366

krichardsson opened this issue Dec 1, 2022 · 0 comments · Fixed by #367
Labels
Milestone

Comments

@krichardsson
Copy link
Contributor

There are a number of "Sync" classes that wraps the asynchronous nature of the python lib in a synchronous API. The behavior of these classes is not good when a Crazyflie is turned off for instance and they all need checked.

The SyncCrazyflie class is probably OK and it is the responsibility of the user to check that the connection still is alive when using the class, for instance by using the is_link_open() method, like this

with SyncCrazyflie(URI) as scf:
    while scf.is_link_open():
        do_something()

Other sync classes or methods, especially those that are blocking must return if the connection is lost to make it possible to exit. For instance the write_sync() method on the DeckMemory class. It may be used like this:

with SyncCrazyflie(URI) as scf:
    deck = findDeckMemory()

    # write_sync() must return if connection is lost, otherwise the next line will hang forever
    deck.write_sync(0, large_blob_of_data)

Code like this can for instance be found in cflib/bootloader/__init__.py and currently this will hang if connection is lost while flashing a deck.

It is probably a good idea to go through all sync implementations in the lib to make sure they are OK

@krichardsson krichardsson transferred this issue from bitcraze/crazyflie-firmware Dec 2, 2022
@ataffanel ataffanel added this to the next-release milestone Dec 12, 2022
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 a pull request may close this issue.

2 participants