[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