To answer question A:
Yes, the delivery and handling of the signal is not entirely transparent to 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) 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.