There remains an extremely unlikely use-after-free race in rotary_encoder_delete, which cannot be practically solved without updates in ESP-IDF.
Given the unlikeliness of the race, and that rotary_encoder_delete will often never be called, or only called during system teardown, this isn't a practical concern. In theory, it could happen that a call to rotary_encoder_delete pre-empts the timer callback in the very narrow window between the callback entry and the acquisition of the lock (this pre-emption isn't likely to ever happen in practice). In that case, rotary_encoder_delete could free the memory containing the lock before the callback attempts to acquire it.
ESP-IDF master contains a new method, esp_timer_stop_blocking (espressif/esp-idf@8569da1), which will resolve this completely. Once this method is available in a stable release, this library should switch to it, and the mutex can likely be removed entirely.
There remains an extremely unlikely use-after-free race in
rotary_encoder_delete, which cannot be practically solved without updates in ESP-IDF.Given the unlikeliness of the race, and that
rotary_encoder_deletewill often never be called, or only called during system teardown, this isn't a practical concern. In theory, it could happen that a call torotary_encoder_deletepre-empts the timer callback in the very narrow window between the callback entry and the acquisition of the lock (this pre-emption isn't likely to ever happen in practice). In that case,rotary_encoder_deletecould free the memory containing the lock before the callback attempts to acquire it.ESP-IDF master contains a new method,
esp_timer_stop_blocking(espressif/esp-idf@8569da1), which will resolve this completely. Once this method is available in a stable release, this library should switch to it, and the mutex can likely be removed entirely.