On Mon, Apr 09, 2001 at 04:57:51PM -0700, Jim Wilcoxson wrote:
> I know that a sleep() call can return EINTR. It means an event like a
> signal delivery caused the sleep() system call to be interrupted.
>
> Not sure what it means if a read call returns this result, because
> EINTR (with sleep()) means that the system call did partially execute.
> So in the case of read(), it could be that part of the data requested
> was read. If that is true, it seems like the OS should return the
> number of bytes read instead of EINTR. If the read() did not execute
> and the file descriptor is non-blocking, read() could return zero or
> EAGAIN.
>
> Maybe this is a case where the f.d. is configured to block and read()
> has not yet read any data when the signal occurs. In that case,
> returning zero bytes usually means EOF (which is wrong), and returning
> EAGAIN is probably only legal on non-blocking descriptors. So it
> is returning EINTR. I think the thing to do is retry the read,
> although if you are having this problem in this specific case, it
> probably exists in other circumstances as well (not just exec).
>
> Jim
'man' is a wonderful thing:
man read
:: snip ::
[EINTR] A read from a slow device was interrupted before any data
arrived by the delivery of a signal.
