I can confirm that many filesystem operations can fail with EINTR when
operating over NFS. However, someone had to be causing the signals in
question - SIGALRM, maybe, or keyboard SIGINT, etc. Protecting stat() is
usually the most important remedy, since failure will cause you to think
that a file does not exist, even
though it does. The big question is what is generating the signals -
presumably
it's SIGCHLD in this case, and there's probably not much you can do about
that.
-- Howard Chu
Chief Architect, Symas Corp. Director, Highland Sun
http://www.symas.com http://highlandsun.com/hyc
> -----Original Message-----
> From: Paul D. Smith [mailto:[EMAIL PROTECTED]]
> Sent: Wednesday, May 31, 2000 12:22 PM
> To: Michael Sterrett -Mr. Bones.-
> Cc: [EMAIL PROTECTED]
> Subject: Re: -j fails on DYNIX/ptx
>
>
> %% "Michael Sterrett -Mr. Bones.-" <[EMAIL PROTECTED]> writes:
>
> ms> Do the specifications say that EINTR is not required or that it
> ms> is forbidden?
>
> Hmm. They say that a function may have more return error codes than
> listed in the standards, so you're right: I guess there's nothing
> technically preventing EINTR.
>
> stat() is listed as required to be safe to call within a signal handler,
> which isn't directly related of course.
>
> ms> EINTR A signal was caught during the stat() or
> ms> lstat() function.
>
> ms> Without the code, there's no way for me to know if Solaris will
> ms> actually ever fail with EINTR, but the man pages seems
> to indicate
> ms> that it *could*.
>
> I suspect, but can't prove, that you won't get EINTR from stat(2) for
> "normal" filesystems.
>
> ms> I guess I'm still not convinced that this problem couldn't be
> ms> reproduced if sufficiently adverse conditions were
> ms> encountered, even on "normal" UNIX systems. I'm for adding
> ms> the loop on EINTR to the GNU make code base.
>
> I just find it hard to believe that there have been no other reported
> cases of this anywhere else; if it's possible, no matter how obscure, it
> seems like _someone_ else would have hit it somewhere, by now. Sigh.
>
> The problem is, there are a number of places that use stat(2) in GNU
> make in addition to this one. Do we need to armor them all? What about
> other system calls?
>
> If this is a real (even potential) problem for most/all OS's, then maybe
> a different solution than wrapping all the system calls in EINTR checks
> is in order.
>
> --
> ------------------------------------------------------------------
> -------------
> Paul D. Smith <[EMAIL PROTECTED]> Find some GNU make tips at:
> http://www.gnu.org
http://www.ultranet.com/~pauld/gmake/
"Please remain calm...I may be mad, but I am a professional." --Mad
Scientist
