EINTR always retries?

[rrnewton]

Some system calls (e.g. open) get interrupted in the middle by a signal. The safe thing to do is just retry them and ensure determinism rather than bombing the job.

The problem is that in the ptrace model we don't have a simple way to just RETRY a system call. We could move the PC pointer up to replay that part of the computation. But would need to be able to restore the arguments.

It's important to know which system calls MUTATE the memory space of the process that calls them. (And if those mutations are idempotent....)

We are thinking of some system calls that take a pointer argument and populates a piece of heap memory at that address. Sometimes the behavior is conditional (because it might depend on whether something is zero). We need to look out for these.

[Recall: we need a retrying capability for read syscalls anyway (#20)]

[rrnewton]

The counter-proposal is that we control the signals and avoid the EINTR in the 1st place.
That sounds pretty appealing, because the man pages are quite clear, that only signals should cause EINTR.

[rrnewton]

I'm going to close this issue for now, on the theory that we will indeed prevent EINTR from every happening. If we cannot maintain that invariant, let's come back, reopen this, and then turn it into a retry.

[devietti]

Reopening this until we are actually catching EINTR and throwing a runtime_error. Probably should do this in a blanket way for all system calls.