**To answer question A**: Yes, the delivery and handling of the signal is not entirely transparent to the `read()`. The `read()` running halfway may be occupying some resources while it's interrupted by the signal. And the signal handler of the signal may call another `read()` (or any other [async-signal safe syscalls](http://www.linuxmisc.com/29-unix-internals/94c18aa80a636196.htm)) as well. So the `read()` interrupted by the signal must be stopped first in order to release the resources it uses, otherwise the `read()` called from the signal handler will access the same resources and cause reentrant issues. Because system calls other than `read()` could be called from the signal handler and they may also occupy identical set of resources as `read()` does. To avoid reentrant issues above, the simplest, safest design is to stop the interrupted `read()` every time when a signal happens during its run.