On Wed, 31 May 2000, Paul D. Smith wrote:
> OK, I've investigated this further. The reason you never see this
> problem on "normal" UNIX systems is that it's not legal for stat(2) to
> fail with EINTR. In other words, stat(2) is not interruptible, by
> definition, due to signals. Looking at both the POSIX and SingleUNIX
> specifications for stat(2), EINTR is not a legal error state when
> stat(2) returns.
>
> Two solutions immediately present themselves:
>
> 1) Just wrap stat(2) in a loop checking for EINTR, even though that's
> not possible on any standard UNIX system. I don't think this would
> be much of a slowdown in the code, but others might disagree (for
> sure this stat(2) is one of the most common system calls make uses).
>
> 2) Use a configure check for this OS (I don't see how a configure macro
> for this can easily be written) and only wrap the stat(2) in an
> EINTR loop on this OS (i386-sequent-sysv4).
Paul -
Do the specifications say that EINTR is not required or that it
is forbidden?
From the man page for stat(2) on Solaris:
--------------------------------------CUT---------------------------------------
ERRORS
stat() and lstat() fail if one or more of the following are
true:
EINTR A signal was caught during the stat() or
lstat() function.
--------------------------------------CUT---------------------------------------
Without the code, there's no way for me to know if Solaris will
actually ever fail with EINTR, but the man pages seems to indicate
that it *could*.
I guess I'm still not convinced that this problem couldn't be
reproduced if sufficiently adverse conditions were encountered, even
on "normal" UNIX systems. I'm for adding the loop on EINTR to the
GNU make code base.
Thanks for your work on this,
Michael Sterrett
-Mr. Bones.-
[EMAIL PROTECTED]
