From ee5d5b9a8c4d3bd77c86aacc4b4a15210051e399 Mon Sep 17 00:00:00 2001 From: Willy-JL <49810075+Willy-JL@users.noreply.github.com> Date: Sun, 10 Sep 2023 03:07:10 +0200 Subject: [PATCH] Fix view_port_update() apps random deadlocks --- applications/services/gui/view_port.c | 18 ++++++++++++++++-- 1 file changed, 16 insertions(+), 2 deletions(-) diff --git a/applications/services/gui/view_port.c b/applications/services/gui/view_port.c index 6723a777bb..7b6644d306 100644 --- a/applications/services/gui/view_port.c +++ b/applications/services/gui/view_port.c @@ -174,9 +174,23 @@ void view_port_input_callback_set( void view_port_update(ViewPort* view_port) { furi_assert(view_port); - furi_check(furi_mutex_acquire(view_port->mutex, FuriWaitForever) == FuriStatusOk); + // view_port_update() does not modify viewport memory + // nor does it need time sensitive data in order to work + // but when used in apps in a input loop it can cause deadlocks with draw() being called by other means + // example: + // - app selector keeps loading animation in background, keeps drawing + // - because of this gui starts draw and locks viewport mutex, not in app render callback yet + // - app gets input, locks app mutex + // - app input handler calls view_port_update() which needs viewport mutex + // - viewport mutex already locked by draw previously + // - but app mutex locked by input so draw cannot complete + // - DEADLOCK => mutex removed from view_port_update() + // this is just one example, there may be many more edge cases + // point is, this view_port_update() has no need at all for mutex + // dont copy paste mutex into all functions to close jira tasks please :) + // furi_check(furi_mutex_acquire(view_port->mutex, FuriWaitForever) == FuriStatusOk); if(view_port->gui && view_port->is_enabled) gui_update(view_port->gui); - furi_check(furi_mutex_release(view_port->mutex) == FuriStatusOk); + // furi_check(furi_mutex_release(view_port->mutex) == FuriStatusOk); } void view_port_gui_set(ViewPort* view_port, Gui* gui) {