TUI: block signals on suspend (avoid kernel panic #8075)

[Code-Hex]

This is only temporary, but it seems that kernel panic was occurring when sending signals to race when suspending, so I created a PR to fix it. #8075

I tried on macOS 10.14.5（18F132）
Terminal.app, iTerm2 (Build 3.3.9), bash 5.0, bash 3.2, zsh 5.7.1

[justinmk]

Nice, thank you!

This is only temporary

you mean, because we will switch to coprocesses instead of threads?

[Code-Hex]

@justinmk Currently, the kernel panic actions (ctrl-z, ctrl -d, ctrl -d) do not perform the exit process that should have been done. I think it's the right way to call preserve_exit when exiting by any signals.

Looking back on this action.

1. ctrl-z => this will be handled by neovim and go to suspend state
2. ctrl-d => handled by shell and warned that there are still suspend processes (`you have suspended jobs.`).
3. ctrl-d => handled by shell. then the shell is terminated and some child processes are received signal to exit (zsh: SIGHUP, bash: SIGTERM)

I put a lot of logs in suspend_event and found out that after the execution of 3, two handlers, one for SIGCONT and one for EXIT SIGNAL (deadly_signal), were executed and entered the race state.

I don't think the SIGCONT handler should be executed in this case.

So, I think it's really necessary to process each received signal one by one, using mutual processing or event queues.

I believe this fix is only temporary in the meantime.

This is only temporary

I think there is probably a problem between

stream_set_blocking(input_global_fd(), false);
CONTINUE(data->bridge);

in suspend_event function and some functions in the exit process.

[Code-Hex]

I also looked at syscalls called, so I put a log of those as well. I think the part after "kill" is the relevant part. (Please search for "kill.")
https://gist.github.com/Code-Hex/1f987ea46db24d2898aeec281f0ca2cf