[OpenAFS-devel] CopyOnWrite failure and EINTR

[Patrick J. LoPresti]

Sam Hartman <hartmans@mekinok.com> writes:

> This problem certainly is real and is happening to other people as
> well.  When I looked at it, I convinced myself that errno of EINTR
> was just an artifact--just what was currently sitting in erno and
> that the read call was failing with EOF not with an error.

I thought read() returned zero on EOF and only returned -1 on a real
error.  Does the code in question not distinguish between these
outcomes?

This may be an argument for setting "errno = 0" just before the
read().

Also, this sort of "faulty errno" problem can be caused by signal
handlers which do not preserve errno.  Any signal handler which makes
system calls should preserve errno.  Failing to do so can create
particularly pernicious bugs, because basically all code (including
the C library) referencing errno assumes is not going to be modified
asynchronously.  Bash 1.x actually had a bug of this sort in its
SIGCHLD handler which generated an "impossible" ECHILD return from a
read() call.

 - Pat