Closed yshavit closed 1 year ago
Update: I also removed the pipe from the SIGWINCH side of things, so that we don't have any pipes/sockets at all. Each path just grabs its events as simply as possible (for stdin, just read forever; for sigwinch, using the Signals
iterator) and sends them to the mpsc channel.
fwiw, this seems to work fine on Ubuntu 22.04
@PaulJuliusMartinez any thoughts on this one? Even if you don't release a new version of jless, it'd be nice to just get this PR off my queue if it's acceptable to you. (Or to close it if it's not.)
Closing this PR for lack of development on the project. @PaulJuliusMartinez feel free to reopen and merge if you want.
By using a channel, we can remove the need for calling
libc::poll
on the stdin pipe. This doesn't work on the Mac: when we redirect tty to stdin, it breaks the original stdin pipe (fd 0), such thatlibc::poll
on it returns instantly, with an revents of POLLNVAL (invalid pipe). Also, macOS doesn't supportlibc::poll
on devices, so we can't poll tty directly.Instead, we spawn two threads: one just reads stdin forever, and the other uses the socket to listen for SIGWINCH events as before (using
libc::poll
). These both write to a channel, and theTuiInput
simply reads from this channel.There's no attempt to interrupt or join the two threads: they both just go on as long as the program does. I can add a "stop listening" signal if you like, but that felt like unnecessary complication given the current flow.
This fixes #2.