4 ms·

Wow. I mean, wow Apple. I come from linux, I'm used to screwed up APIs, and stuff breaking. But when we have something broken, it's usually because it was desi

Wow. I mean, wow Apple. I come from linux, I'm used to screwed up APIs, and stuff breaking. But when we have something broken, it's usually because it was designed that way (see epoll). Usually, anyways. But even we would never break something this fundamental. And if it did break, we'd probably fix it. Immediately. Breaking one of the most used syscalls in the POSIX spec isn't an option, and is never okay. Ever.

rwmj 10y ago
In released products, no. In development kernels it's a bit more like the wild west. It was only a few years ago that dup3(2) was broken in a development kernel. That's a very fundamental syscall, especially when you consider that some libraries replace all dup2 with dup3 to get O_CLOEXEC behaviour. Of course these things get fixed very rapidly, so completely unlike this Apple/poll story.
- qwertyuiop924 10y ago
  Well, of course things will break in development, that's to be expected. But once it's been released...
  - rwmj 10y ago
    I was perhaps being stary-eyed and naive, but I expected that Linux would have a comprehensive test suite which would catch this sort of thing, at least for the most common syscalls.
    - qwertyuiop924 10y ago
      I assume that they at least test, and may even test before integrating, but when things are merged into HEAD, changes in various subsystems might affect one another, or some such.
athenot 10y ago
It's a similar situation: macOS has kqueue. But in this case, they are using poll as the time-honored way to sleep. Yes Apple should follow the expected POSIX behavior but at the same time if sleep is what is desired, there's usleep(3) and nanosleep(2) which are found in libc's time.h
- qwertyuiop924 10y ago
  It's not a similar situation at all: Linux doesn't break POSIX semantics (well, not here: MADV_DONTNEED has an... "interesting" interpretation of POSIX, so there's at least one violation, but that's not the exact topic of discussion, and seeing as it's not one of the most used syscalls in POSIX, it's less of a problem. Although it's still bad. If you're interested in the sins of the Linux kernel, you can go see Bryan Cantrill's lightning talk on the subject).
  - vvhn 10y ago
    If you closely enough at the spec, it is unclear if this actually a violation. Also, according to the developer, this same behavior was present from 10.3 to 10.9 ( Apple was certified to be compliant from 10.5 onwards which tells you that this isn't non conformant) and OS X did not even ship with a poll(2) implementation before 10.3 .
    - qwertyuiop924 10y ago
      If you look closely enough at the spec, almost anything is conformant. But it's generally acknowledged that breaking everybody's code is a Bad Thing. It's also possible that the test suite just doesn't check for this. In any case, the behavior is necessary for any application that polls against a set of fds of varying size, as the fd set may shrink to zero before expanding again, and and punishing the developer for not checking as special case that all other unixes handle automatically is pretty unfair.
  - SysArchitect 10y ago
    Bryan Cantrill's lightning talk: https://youtu.be/bg6-LVCHmGM?t=3521 https://youtu.be/bg6-LVCHmGM?t=3521

rwmj 10y ago

In released products, no. In development kernels it's a bit more like the wild west. It was only a few years ago that dup3(2) was broken in a development kernel. That's a very fundamental syscall, especially when you consider that some libraries replace all dup2 with dup3 to get O_CLOEXEC behaviour. Of course these things get fixed very rapidly, so completely unlike this Apple/poll story.

qwertyuiop924 10y ago
Well, of course things will break in development, that's to be expected. But once it's been released...
- rwmj 10y ago
  I was perhaps being stary-eyed and naive, but I expected that Linux would have a comprehensive test suite which would catch this sort of thing, at least for the most common syscalls.
  - qwertyuiop924 10y ago
    I assume that they at least test, and may even test before integrating, but when things are merged into HEAD, changes in various subsystems might affect one another, or some such.

athenot 10y ago

It's a similar situation: macOS has kqueue. But in this case, they are using poll as the time-honored way to sleep. Yes Apple should follow the expected POSIX behavior but at the same time if sleep is what is desired, there's usleep(3) and nanosleep(2) which are found in libc's time.h

qwertyuiop924 10y ago
It's not a similar situation at all: Linux doesn't break POSIX semantics (well, not here: MADV_DONTNEED has an... "interesting" interpretation of POSIX, so there's at least one violation, but that's not the exact topic of discussion, and seeing as it's not one of the most used syscalls in POSIX, it's less of a problem. Although it's still bad. If you're interested in the sins of the Linux kernel, you can go see Bryan Cantrill's lightning talk on the subject).
- vvhn 10y ago
  If you closely enough at the spec, it is unclear if this actually a violation. Also, according to the developer, this same behavior was present from 10.3 to 10.9 ( Apple was certified to be compliant from 10.5 onwards which tells you that this isn't non conformant) and OS X did not even ship with a poll(2) implementation before 10.3 .
  - qwertyuiop924 10y ago
    If you look closely enough at the spec, almost anything is conformant. But it's generally acknowledged that breaking everybody's code is a Bad Thing. It's also possible that the test suite just doesn't check for this. In any case, the behavior is necessary for any application that polls against a set of fds of varying size, as the fd set may shrink to zero before expanding again, and and punishing the developer for not checking as special case that all other unixes handle automatically is pretty unfair.
- SysArchitect 10y ago
  Bryan Cantrill's lightning talk: https://youtu.be/bg6-LVCHmGM?t=3521 https://youtu.be/bg6-LVCHmGM?t=3521