From reading the man pages on the 'read()' and 'write()' calls it appears that these calls get interrupted by signals regardless of whether they have to block or not.

• a process establishes a handler for some signal.
• a device is opened ( say a terminal .... ) with the 'O_NONBLOCK' NOT set ( i.e. operating in blocking mode  )
• the process then makes a 'read()' system call to read from the device and as a result executes a kernel control path in kernel-space.
• while the precess is executing its 'read()' in kernel-space, the signal for which the handler was installed earlier is delivered to that process and its signal handler is invoked.

Reading the man pages and the appropriate sections in SUSv3 'System Interfaces volume (XSH)' one finds that:

i. If a read() is interrupted by a signal before it reads any data ( i.e. it had to block because no data was available  ), it returns -1 with 'errno' set to [EINTR].

ii. If a read() is interrupted by a signal after it has successfully read some data ( i.e. it was possible to start servicing the request immediately  ), it returns the number of bytes read

Question A):

Am I correct to assume that in either case (block/no block) the delivery and handling of the signal is not entirely transparent to the 'read()'?

Case i. seems understandable since the blocking 'read()' would normally place the process in the 'TASK_INTERRUPTIBLE' state so that when a signal is delivered, the kernel places the process into 'TASK_RUNNING' state.

However when the 'read()' doesn't need to block ( case ii.  ) and is processing the request in kernel-space, I would have thought that the arrival of a signal and its handling would be transparent much like the arrival and proper handling of a HW interrupt would be. In particular I would have assumed that upon delivery of the signal, the process would be temporarily placed into USER-MODE to execute its signal handler from which it would return eventually to finish off processing the interrupted 'read()' ( in kernel-space  ) so that the 'read()' runs its course to completion after which the process returns back to the point just after the call to 'read()' ( in user-space  ), with all of the available bytes read as a result.

But ii. seems to imply that the 'read()' is interrupted, since data is available immediately BUT it returns returns 'some' of the data ( instead of all  ).

This brings me to my second ( and final  ) question

Question B):

If my assumption under A) is correct, why does the 'read()' get interrupted, even though it does not need to block because there is data available to satisfy the request immediately? In other words, why is the 'read()' not resumed after executing the signal handler, eventually resulting in all of the available data ( which was avialable after all  ) to be returned?

From reading the man pages on the read() and write() calls it appears that these calls get interrupted by signals regardless of whether they have to block or not.

• a process establishes a handler for some signal.
• a device is opened (say, a terminal) with the O_NONBLOCK not set (i.e. operating in blocking mode)
• the process then makes a read() system call to read from the device and as a result executes a kernel control path in kernel-space.
• while the precess is executing its read() in kernel-space, the signal for which the handler was installed earlier is delivered to that process and its signal handler is invoked.

Reading the man pages and the appropriate sections in SUSv3 'System Interfaces volume (XSH)', one finds that:

i. If a read() is interrupted by a signal before it reads any data (i.e. it had to block because no data was available), it returns -1 with errno set to [EINTR].

ii. If a read() is interrupted by a signal after it has successfully read some data (i.e. it was possible to start servicing the request immediately), it returns the number of bytes read.

Question A): Am I correct to assume that in either case (block/no block) the delivery and handling of the signal is not entirely transparent to the read()?

Case i. seems understandable since the blocking read() would normally place the process in the TASK_INTERRUPTIBLE state so that when a signal is delivered, the kernel places the process into TASK_RUNNING state.

However when the read() doesn't need to block (case ii.) and is processing the request in kernel-space, I would have thought that the arrival of a signal and its handling would be transparent much like the arrival and proper handling of a HW interrupt would be. In particular I would have assumed that upon delivery of the signal, the process would be temporarily placed into user mode to execute its signal handler from which it would return eventually to finish off processing the interrupted read() (in kernel-space) so that the read() runs its course to completion after which the process returns back to the point just after the call to read() (in user-space), with all of the available bytes read as a result.

But ii. seems to imply that the read() is interrupted, since data is available immediately, but it returns returns only some of the data (instead of all).

This brings me to my second (and final) question:

Question B): If my assumption under A) is correct, why does the read() get interrupted, even though it does not need to block because there is data available to satisfy the request immediately? In other words, why is the read() not resumed after executing the signal handler, eventually resulting in all of the available data (which was available after all) to be returned?