As for the second part, I understand why system calls are interruptible, particularly before the implementation of many syscall-level asynchronous operations. However, too many languages require too much boilerplate in the much, much more common case where the developer wants the appearance of an uninterruptable system call in a multi-threaded and/or multi-actor program.

I've written plenty of interruption-safe sleep and I/O code in C. It's disappointing that same C boilerplate needs to be used in PHP, Java, etc. If you want to expose the interruptiblity of a C sleep(), call it interruptible_sleep(), and make sleep() a wrapper that contains the boilerplate you want 99% of the time in C. I dare say 90+% of programmers don't properly deal with interrupted sleep system calls, and exposing the interruptions should be opt-in.

In retrospect, at the syscall level, the C library interface to interruptible syscalls should take a function pointer to an interruption handler that returns a boolean as to whether the syscall should be transparently resumed. Passing a null handler should result in the syscall appearing uninterruptable to the calling code. Most programmers are blissfully ignorant of interrupted syscalls and are perplexed by seemingly random resultant bugs. The default interface to these calls should protect the programmer.

  // sleep(int sec) should look more like:
  void sleep(int sec) {
    sleep_interruptible(null, sec);
  }

  void sleep_interruptible(bool (*handler)(int), int sec) {
      struct timespec ts = {sec, 0};
      int prev_errno = errno;
      errno = EOK;
      while (nanosleep(&ts, &ts) != 0 && errno == EINTR) {
        if (handler != null && ! handler(errno))
          break;
      }
      errno = prev_errno;
  }