Date: Wed, 31 May 2000 14:22:39 -0400 (EDT)
From: "Paul D. Smith" <[EMAIL PROTECTED]>
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.
Actually, EINTR is possible on
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
%% "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
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 bo
%% "Michael Sterrett -Mr. Bones.-" <[EMAIL PROTECTED]> writes:
Re: an issue with GNU make 3.78 and above on DYNIX/ptx...
ms> $ gmake --version
ms> GNU Make version 3.78.1, by Richard Stallman and Roland McGrath.
ms> Built for i386-sequent-sysv4
ms> $ uname -a
ms> DYNIX/ptx
Sorry folks false alarm. It seems that the Imake that generated the
makefiles that GNU make died on was the culprit as it wasn't being built
correctly for some reason and so generated bad rules.
Regards,
Mark Syms
> -Original Message-
> From: Mark Syms
> Sent: Wednesday, May 24
