[Vm-dev] Interrupted system call?
Ian Piumarta
piumarta at speakeasy.net
Wed Feb 11 02:38:50 UTC 2009
Hi Andreas,
On Feb 10, 2009, at 5:48 PM, Andreas Raab wrote:
> I've seen references to that particular error in the Unix VM in
> other discussions. We have this problem right now in a slightly
> different context (an external library call reports that error) and
> I am wondering if someone can explain to me what causes this error
The process is in a kernel system call when a lack of resource in
blocking i/o (or a high-priority asychronous event) causes the
process to be suspended. A decent OS would save the process state
reflecting its being halfway through the syscall such that at
resumption it would continue the syscall, transparently to the user.
Saving this state, in kernel mode and intermediate between two valid
user-mode states, is very hard. (Think about what would be needed if
an asychonous signal arrived for a process suspended halfway through
a syscall, for example.) Unix, being particularly pragmatic but not
particularly decent, choses instead to abort the syscall but to act
as if it was completed (the user process resumes after the point of
the call, not at it) but with a failure code (EINTR) to indicate the
call was aborted. The caller (the user's program) is expected to
deal with this by restarting the syscall explicitly, with
(presumably) identical arguments.
Google for "pc losering problem" (with the quotes) if you need more
on this.
> and whether there is a way to "fix" the Unix VM not to cause it.
You might be able to drastically reduce the number of asychronous
signals (and hence the likelihood of an interrupted syscall) by
counting milliseconds with gettimeofday() instead of with periodic
timer interrupts. '-notimer' (SQUEAK_NOTIMER) is the option
(environment variable), IIRC.
The pragmatically correct way to deal with this is to wrap each and
every syscall in a Unix program in sometime like this:
while (EINTR == (err= syscall(whatever, ...)));
if (err) { deal with it }
The philosophically correct way to deal with it is to use an OS that
isn't Unix.
> Thanks for any insights!
I'm not sure that the above was insightful, but I hope it was
explanatory.
Cheers,
Ian
More information about the Vm-dev
mailing list