3 deleted 5 characters in body
source | link

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) 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 it's runningits run.

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) 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 it's running.

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) 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.

2 added 298 characters in body
source | link

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) 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 it's running.

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) 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.

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) 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 it's running.

1
source | link

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) 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.