On Mon, Apr 09, 2001 at 07:51:43PM -0500, Robert Hentosh wrote:
> 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.
Well it seems that the linux man has EINTR being valid also. Shouldn't
the read in ParseFile() contained in nsd/adp.c be wrapped also? I believe
there is supposed to be some caching for ADP's... is there a way I can
turn off caching so the ADP's are constantly re-read to test this code?
I guess some load testing needs to be done while hitting exec pages, too.
What other child proc's does one need to worry about dying outside of the
tcl exec?
