From 2da2449777d68520eed8f888de2c256e04662722 Mon Sep 17 00:00:00 2001 From: "jabber.developer2" Date: Fri, 29 May 2026 08:48:25 +0300 Subject: [PATCH] fix(ui): release global lock around suspend-branch sleep in inp_readline The normal path of inp_readline unlocks the global `lock` around select(), giving worker threads (http_upload / http_download / ai_client in src/tools and src/ai) a window to acquire it and update the UI. The suspend branch (entered while an external editor is active) used to g_usleep(100000) and return NULL while holding the lock, so the main thread monopolised it for the whole editor session and every in-flight transfer froze; on a long composition (the customer's main /editor use case) this could be long enough for server-side timeouts to fire. Mirror the normal-path unlock / sleep / lock pattern so the same window exists during the editor session. Workers in the suspended state print through wnoutrefresh paths only (no direct doupdate / refresh / wrefresh in src outside core.c / inputwin.c, all of which are already guarded against suspended writes), so opening the window introduces no new race. --- src/ui/inputwin.c | 6 ++++++ 1 file changed, 6 insertions(+) diff --git a/src/ui/inputwin.c b/src/ui/inputwin.c index b3629861..6e98af02 100644 --- a/src/ui/inputwin.c +++ b/src/ui/inputwin.c @@ -182,7 +182,13 @@ inp_readline(void) { // UI is suspended if (is_suspended || isendwin()) { + // Mirror the normal-path unlock/sleep/lock so worker threads + // (http_upload / http_download / ai_client) can acquire `lock` + // during the editor session — otherwise the main thread holds + // it continuously and every in-flight transfer freezes. + pthread_mutex_unlock(&lock); g_usleep(100000); // 100ms + pthread_mutex_lock(&lock); return NULL; }