Dear Maintainer,

Occasionally, I will see urxvtc process become unresponsive to keyboard
input.  It seems like processes may still be able to update their panes - my
mosh session keeps updating the screen, for instance.

Here's a backgrace, for whatever it's worth:

(gdb) thread apply all bt

Thread 1 (Thread 0x7fde1b89a880 (LWP 11263)):
#0  0x00007fde1c77b28e in __libc_read (fd=4, buf=buf@entry=0x7ffc76da48c0,
nbytes=nbytes@entry=536) at ../sysdeps/unix/sysv/linux/read.c:26
#1  0x0000560eae378d63 in read (__nbytes=536, __buf=0x7ffc76da48c0,
__fd=<optimized out>) at /usr/include/x86_64-linux-gnu/bits/unistd.h:44
#2  0x0000560eae378d63 in serve() () at ./../libptytty/src/proxy.C:158
#3  0x0000560eae3790a7 in ptytty::use_helper() () at
./../libptytty/src/proxy.C:268
#4  0x0000560eae379111 in ptytty::use_helper() () at
./../libptytty/src/proxy.C:318
#5  0x0000560eae379111 in ptytty::init() () at ./../libptytty/src/proxy.C:318
#6  0x0000560eae355349 in main(int, char**) (argc=3, argv=0x7ffc76da4cc8) at
rxvtd.C:230
(gdb)

I can spawn new urxvtc processes (using urxvtcd); they display the shell
prompt but do nothing further.  (Had to use a different emulator to run
reportbug.)

Thanks,
--Robbie

Dear Maintainer,

I've gotten a few more of these lockups (two today).  They all look about the
same.  Here's one of the tracebacks:

(gdb) thread apply all bt

Thread 1 (Thread 0x7f7a8ee7f880 (LWP 11279)):
#0  0x00007f7a8fd6328e in __libc_read (fd=4, buf=buf@entry=0x7ffc5bc2ff20, nbytes=nbytes@entry=536) at ../sysdeps/unix/sysv/linux/read.c:26
#1  0x000055a8bdabcd63 in read (__nbytes=536, __buf=0x7ffc5bc2ff20, __fd=<optimized out>) at /usr/include/x86_64-linux-gnu/bits/unistd.h:44
#2  0x000055a8bdabcd63 in serve() () at ./../libptytty/src/proxy.C:158
#3  0x000055a8bdabd0a7 in ptytty::use_helper() () at ./../libptytty/src/proxy.C:268
#4  0x000055a8bdabd111 in ptytty::use_helper() () at ./../libptytty/src/proxy.C:318
#5  0x000055a8bdabd111 in ptytty::init() () at ./../libptytty/src/proxy.C:318
#6  0x000055a8bda99349 in main(int, char**) (argc=3, argv=0x7ffc5bc30328) at rxvtd.C:230
(gdb)

Causing the read call to immediately return launches us back into an
epoll_wait (still on fd=4).  Unsurprisingly, close(4) then caused the daemon
to crash, terminating all clients.

Thanks,
--Robbie