mjhjmtu

The overall question is simple:

How to gracefully resize a window in a multi-thread ncurses program?

Details here. I have read a few relevant questions (1, 2, 3). From my understanding, there are basically 2 ways to handle a window resize:

1. Call endwin followed by refresh in user's own SIGWINCH handler.




2. Leverage ncurses builtin SIGWINCH handler: getch a KEY_RESIZE and handle it.

I have tested on my ncurses implementation to make sure I can receive KEY_RESIZE. But I still don't understand how signal handler works with multi-thread ncurses program:

1. If I'm using the builtin SIGWINCH handler, which thread will be running the signal handler? Does this matter? Do I have control over this?




2. The builtin SIGWINCH handler generates a KEY_RESIZE. But what if there are other keys pressed that haven't been delivered? Is KEY_RESIZE guaranteed to be the key returned by the next call of getch?




3. Handling KEY_RESIZE looks less painful than writing my own SIGWINCH handler. But how can I read this key as soon as it is delivered to make the UI responsive? Can I select or poll stdin to detect its delivery? Is it put on an internal queue that only has something to do with getch but nothing to do with stdin?




4. If I'm writing my own SIGWINCH handler, do I have any guarantee about ncurses context so that my signal handler code won't break ncurses (by calling functions that cannot be called at the time the signal is delivered, etc.)?




5. Is ncurses itself single-threaded or multi-threaded? If I block the SIGWINCH signal on all my threads other than the main thread, am I guaranteed to receive the SIGWINCH signal on the main thread (but not an internal thread created by the ncurses library)?