| Interrupted System Calls reading from NFS on Sun Solaris [message #2369] |
Mon, 27 June 1994 12:16  |
sitongia
Messages: 4
Registered: August 1993
|
Junior Member |
|
|
I haven't gotten anywhere with Sun or RSI on this one yet, so I'm wondering
if anyone else has seen this and has some insights. A program running under
IDL on a Sun running Solaris 2.3 will read data from another Sun over NFS
and barf about an "Interrupted system call". Moments later, run again, it
works fine.
IDL> filtcal
% OPENR: Error opening file: /swing/d/lites/invert/op07_std/a___header.
Interrupted system call
% Execution halted at READ_FLOATS </home/hao/stokes/src/idl/read_floats.pro(
34)> (OPENR).
% Called from B_IMAGE_STR </home/hao/stokes/src/idl/b_image.pro( 74)>.
% Called from B_IMAGE </home/hao/stokes/src/idl/b_image.pro( 205)>.
% Called from C_IMAGE_STR </home/hao/stokes/src/idl/c_image.pro( 62)>.
% Called from C_IMAGE </home/hao/stokes/src/idl/c_image.pro( 239)>.
% Called from FILTCAL <azcal.pro( 262)>.
% Called from $MAIN$ .
IDL> filtcal
lightness.pal
IDL>
Anyone else seen this sort of thing before? I've applied plenty of patches,
and this problem isn't in the Sun bugs database. Could it be caused by a
hardware problem?
Thanks,
Leonard
---
--Leonard E. Sitongia HAO Sun Unix System Manager
sitongia@ncar.ucar.edu voice: (303)497-1509 fax: (303)497-1589
High Altitude Observatory P.O. Box 3000 Boulder CO 80307 USA
|
|
|
|
| Re: Interrupted System Calls reading from NF [message #2436 is a reply to message #2369] |
Thu, 30 June 1994 10:56  |
sitongia
Messages: 4
Registered: August 1993
|
Junior Member |
|
|
In article ar9@ncar.ucar.edu, caron@acd.ucar.edu (John Caron) writes:
> I know that interrupted system calls in UNIX are a normal occurence. The
> correct thing to do is (almost always) to simply re-issue the call.
> (See Leffler et al, p 47-48). What is surprising is that this behavior
> is seen at this high of an API. Typically you are using some library routine
> that takes care of it (e.g. fread()). What is READ_FLOATS actually calling?
> If it is calling an i/o routine that does not handle return EINTR, (read() ?)
> then I would guess that the correct solution is that READ_FLOATS should
> handle it (by looking for it and then reissuing read), and not
> allow it to propagate up.
Thank you for your explanation. READ_FLOATS is calling READU. Perhaps there's
a way to do error handling and retry the read in READ_FLOATS. At this point
we've been running successfully for a short time since I've removed the "intr"
mount option. The filesystem is automounted hard,fg, without intr. Next I'll
try mounting background to avoid clients hanging, of course.
---
--Leonard E. Sitongia HAO Sun Unix System Manager
sitongia@ncar.ucar.edu voice: (303)497-1509 fax: (303)497-1589
High Altitude Observatory P.O. Box 3000 Boulder CO 80307 USA
|
|
|
|
| Re: Interrupted System Calls reading from NFS on Sun Solaris [message #2437 is a reply to message #2369] |
Thu, 30 June 1994 09:32 |
caron
Messages: 16
Registered: May 1994
|
Junior Member |
|
|
I know that interrupted system calls in UNIX are a normal occurence. The
correct thing to do is (almost always) to simply re-issue the call.
(See Leffler et al, p 47-48). What is surprising is that this behavior
is seen at this high of an API. Typically you are using some library routine
that takes care of it (e.g. fread()). What is READ_FLOATS actually calling?
If it is calling an i/o routine that does not handle return EINTR, (read() ?)
then I would guess that the correct solution is that READ_FLOATS should
handle it (by looking for it and then reissuing read), and not
allow it to propagate up.
I am not sure on the details of how NFS works, but EINTR is gotten when the
system issues a system call that may take a long time to complete (eg I/O)
and a signal comes along that must be serviced. I think that "saving the state"
of the system call is too hard, so after servicing the signal, the OS
just returns from the system call with EINTR, more or less telling the
calling routine to "try again". Probably theres lots more subtleties, but I
think thats the vanilla explanation.
|
|
|
|
comp.lang.idl-pvwave archive
Members
Search
Help
Login
Home
