nick black
nick black
it's important to note that this *does not* happen all the time, so a successful build doesn't mean it's fixed.
i just had a `notcurses-demo` from 3.0.13 hang on exit. i got stack traces: ```c (gdb) thread apply all bt Thread 2 (Thread 0x7f57fab966c0 (LWP 2761558) "notcurses-demo"): #0 futex_wait (futex_word=0x5653640b1d18,...
hrmmm so input thread is blocking on a lock, not in `fgetc()`, interesting! that ought make things a lot simpler.
wow, that locks *hard*, too -- neither ^C nor ^Z break it
hrmmm it's not obvious how the input thread could be blocking on taking `ilock`.
huh `pthread_cond_wait()` holds the lock even when returning an error, huh
so i'm seeing this when running `notcurses-demo` and pressing `q` to exit pretty reliably. in that case, we've just read from the input layer...but we shouldn't have it locked by...
hrmm i can't reproduce the `notcurses-demo` lockup on arbitrary terminals, only on ghostty. very strange!
i've added some debug code. normally when we see `taking lock`, we see `got lock` immediately afterwards: ```c process_escape:2246:walk result on 49 (1): 0 273 process_escape:2246:walk result on 58 (:):...
looks like maybe a path in `internal_get()`? possibly it's getting cancelled in the `fgetc()` and not unlocking? quite possible.