[bug] The thread for `FpsCounter` panics if stdout is closed

[kenoss]

Related: #122

$ wl-screenrec | less
0 fps
0 fps

// SIGINT
thread 'FpsCounter' panicked at library/std/src/io/stdio.rs:1123:9:
failed printing to stdout: Broken pipe (os error 32)
stack backtrace:
   0: rust_begin_unwind
   1: core::panicking::panic_fmt
   2: std::io::stdio::_print
note: Some details are omitted, run with `RUST_BACKTRACE=full` for a verbose backtrace.
^C^C^C^C^Czsh: killed     wl-screenrec |
zsh: done       less

Panicking on closing stdout might be OK (if there's no cleanup), but I expect that it is propagated to the main thread and terminates the process.

I guess that quit_flag is not enough. (And simple join(), too.) FYI, I usually uses std::panic::set_hook() sending an error to a crossbeam channel and select! on the main thread.

[russelltg]

I think I'd just rather it not panic in the first place--but I kinda think the current behavior is better than what you propose. It continues recording properly and everything, just the fps output doesn't work.... (and can't because well no stdout)

[kenoss]

Thanks!