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