zlacker

[parent] [thread] 11 comments
1. sebste+(OP)[view] [source] 2022-12-08 13:47:28
There's less and less wrong with it as we go along, but seriously there's still so much crap... You could list so many other than preg_match

>sleep(int $seconds)

>returns zero on success.

>If the call was interrupted by a signal, sleep() returns a non-zero value. On Windows, this value will always be 192. On other platforms, the return value will be the number of seconds left to sleep.

I've used it for 2 years 2 years ago and I'm not at all interested in starting a project with it again

replies(4): >>mgkims+K1 >>donatj+53 >>xxpor+vd >>within+Mk1
2. mgkims+K1[view] [source] 2022-12-08 14:04:05
>>sebste+(OP)
You must have more than just 'sleep' bothering you. What would you start a project in today?
replies(1): >>sebste+J9
3. donatj+53[view] [source] 2022-12-08 14:13:23
>>sebste+(OP)
A little weird, but it was documented.

PHP is nothing if not amazingly well documented. This is more than I can say for a lot of languages I have worked in cough Ruby cough. I work pretty heavily in Go these days and even it’s docs leave me wanting in comparison sometimes.

replies(2): >>apocal+25 >>sebste+h9
◧◩
4. apocal+25[view] [source] [discussion] 2022-12-08 14:24:31
>>donatj+53
It is well documented but the comments in the documentation are seriously bad most of the time. I really wish they would at least designate the primary release at the time of the comment, if not purge old ones (the comments from 2005 don't often offer much value nearly 20 years later)
◧◩
5. sebste+h9[view] [source] [discussion] 2022-12-08 14:50:53
>>donatj+53
If documenting was enough band saws would still just have warnings about fingers in their manuals instead of guard rails. "Weird functions" need to have big yellow warnings at the top of their doc with a link to fixed versions of the func
◧◩
6. sebste+J9[view] [source] [discussion] 2022-12-08 14:54:18
>>mgkims+K1
When I was using it, I had a novel's worth. Now I mostly forgot my rant

The projects I start today got the php replaced by typescript

7. xxpor+vd[view] [source] 2022-12-08 15:16:10
>>sebste+(OP)
Wait, what's wrong with that?
replies(2): >>KMag+CI >>xigoi+nX
◧◩
8. KMag+CI[view] [source] [discussion] 2022-12-08 17:32:20
>>xxpor+vd
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+yX
◧◩
9. xigoi+nX[view] [source] [discussion] 2022-12-08 18:49:08
>>xxpor+vd
Why 192? Why only on Windows?
replies(1): >>xxpor+672
◧◩◪
10. xxpor+yX[view] [source] [discussion] 2022-12-08 18:49:57
>>KMag+CI
>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?

11. within+Mk1[view] [source] 2022-12-08 20:35:40
>>sebste+(OP)
In my experience, this is a highly useful feature. I’m not sure what you’re complaining about here, but if the server is shutting down, what’s the point in sleeping?
◧◩◪
12. xxpor+672[view] [source] [discussion] 2022-12-09 00:48:06
>>xigoi+nX
Because that's how the underlying syscall works?
[go to top]