zlacker

[parent] [thread] 4 comments
1. xxpor+(OP)[view] [source] 2022-12-08 15:16:10
Wait, what's wrong with that?
replies(2): >>KMag+7v >>xigoi+SJ
2. KMag+7v[view] [source] 2022-12-08 17:32:20
>>xxpor+(OP)
There are 2 issues they might be complaining about: (1) cross-platform issues that seem so trivial that documenting them was probably more work than fixing them and (2) high-level language leaking low-level implementation details.

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;
  }
replies(1): >>xxpor+3K
3. xigoi+SJ[view] [source] 2022-12-08 18:49:08
>>xxpor+(OP)
Why 192? Why only on Windows?
replies(1): >>xxpor+BT1
◧◩
4. xxpor+3K[view] [source] [discussion] 2022-12-08 18:49:57
>>KMag+7v
>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 interruptible 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

I get where you're coming from, I think the way I'd think about it would be a little different. The interruptible part is semi-specific to sleep. I'd want predicable naming for syscalls first and foremost. So something like libc_sleep(). (libc_open(), etc would follow too) This makes is more obvious you're dealing with a pretty raw api. But otherwise agree. I haven't written any PHP in nearly 20 years, so I completely forget: is sleep() pretty typical of how PHP treats these syscalls?

◧◩
5. xxpor+BT1[view] [source] [discussion] 2022-12-09 00:48:06
>>xigoi+SJ
Because that's how the underlying syscall works?
[go to top]