3 ms·

I am not sure what you are trying to argue. It seems to be a well known and accepted fact that kqueue and poll both are buggy on various OS X versions - badly e

I am not sure what you are trying to argue. It seems to be a well known and accepted fact that kqueue and poll both are buggy on various OS X versions - badly enough that Google shows many Open Source projects avoid using both. If you need more proof - the curl site seems to have the code that illustrates the poll bug on iOS per the comment below. If you're saying kqueue isn't buggy because you couldn't find proof - as I said you can investigate more as to why various open source projects don't use it- perhaps there are comments in code, perhaps you can test all osx versions for all the test cases? (The libev docs I linked to clearly state poll is buggy because it's implemented using kqueue.)

eridius 10y ago
I can believe that there are bugs, I just want to know what they are. I'm not going to spend ages trying to test all sorts of corner cases to find out what they are myself. Part of the problem here is that as long as it's "common wisdom" that kqueue is broken, then it doesn't actually matter if it's broken or not, people will continue to repeat that it is. There needs to be actual concrete information about what specifically is broken (and not just "my test app is broken", because as I demonstrated above, your test app may be what's buggy rather than kqueue) so we can track this and confirm that it's still broken on new OS releases. > the curl site seems to have the code that illustrates the poll bug on iOS per the comment below As has been pointed out in this comments section already, a strict reading of the POSIX poll spec could be argued to say that an empty file descriptor set is undefined behavior, so I don't find this one poll bug to be terribly convincing.
- blinkingled 10y ago
  > empty file descriptor set is undefined behavior Umm the behavior of poll changed across os x versions. That's the bug. You don't break user space. Also I'm not sure how you're claiming it's POSIX compliant given - * poll() is defined by POSIX and The Single Unix Specification it specifically says: If none of the defined events have occurred on any selected file descriptor, poll() waits at least timeout milliseconds for an event to occur on any of the selected file descriptors 10.12 and lesser than 10.9 versions poll implementation returns immediately.
  - eridius 10y ago
    The fact that behavior changed doesn't mean it's a bug. If the behavior in question is undefined behavior, then it can be subject to change without warning. And the argument here is that the cited wording assumes a non-empty set of file descriptors, because the way it's worded doesn't make sense if there are no file descriptors. If there are no file descriptors, it's impossible for an event to happen, so there's nothing to wait on.
    - blinkingled 10y ago
      Every other UNIX like platform behaves one way (returns after timeout for empty/NULL fd set) and always has, but if you want to pick the interpretation that makes it a non bug in OS X - then you have to agree that it was buggy under OS X between 10.9 and 10.12! Can't have it both ways :) Also whatever you say - no sane OS vendor keeps alternating between different undefined behaviors causing pain for developers. MS, Linux, FreeBSD - AFAIK they all do everything to not break user space. Linus has famously said - if you break a working userspace binary - it's a bug!
      - eridius 10y ago
        > you have to agree that it was buggy under OS X between 10.9 and 10.12 No you don't. Neither behavior has to be buggy. That's what undefined behavior means, that any and all possible behaviors are valid because no specific behavior is defined as correct. > Linus has famously said - if you break a working userspace binary - it's a bug! That's a very hard-line stance, and it means accidents of implementation become guaranteed behavior which can be extremely restrictive down the line. Linus obviously believes that this philosophy is correct for Linux, but that doesn't mean it's correct for OS X.
        blinkingled 10y ago
        I think this is going beyond reason - not correct for OS X?! What does that mean? It's not just Linux either - MS does the same thing. You don't cause developers and users pain by randomly changing stuff - correct or incorrect to you doesn't factor. If something was working it is a reasonable expectation for any mainstream OS that it will continue to work. If you don't agree with that then your choice - the world hasn't worked that way in a while. It would be one thing if they always consistently returned immediately in poll if you passed NULL but alternating between returning immediately and returning after timeout with no guarantee which OS version will change it again in future - that's madness. Hey but ok - for you I will say it - Apple can do no wrong!

eridius 10y ago

I can believe that there are bugs, I just want to know what they are. I'm not going to spend ages trying to test all sorts of corner cases to find out what they are myself. Part of the problem here is that as long as it's "common wisdom" that kqueue is broken, then it doesn't actually matter if it's broken or not, people will continue to repeat that it is. There needs to be actual concrete information about what specifically is broken (and not just "my test app is broken", because as I demonstrated above, your test app may be what's buggy rather than kqueue) so we can track this and confirm that it's still broken on new OS releases. > the curl site seems to have the code that illustrates the poll bug on iOS per the comment below As has been pointed out in this comments section already, a strict reading of the POSIX poll spec could be argued to say that an empty file descriptor set is undefined behavior, so I don't find this one poll bug to be terribly convincing.

blinkingled 10y ago
> empty file descriptor set is undefined behavior Umm the behavior of poll changed across os x versions. That's the bug. You don't break user space. Also I'm not sure how you're claiming it's POSIX compliant given - * poll() is defined by POSIX and The Single Unix Specification it specifically says: If none of the defined events have occurred on any selected file descriptor, poll() waits at least timeout milliseconds for an event to occur on any of the selected file descriptors 10.12 and lesser than 10.9 versions poll implementation returns immediately.
- eridius 10y ago
  The fact that behavior changed doesn't mean it's a bug. If the behavior in question is undefined behavior, then it can be subject to change without warning. And the argument here is that the cited wording assumes a non-empty set of file descriptors, because the way it's worded doesn't make sense if there are no file descriptors. If there are no file descriptors, it's impossible for an event to happen, so there's nothing to wait on.
  - blinkingled 10y ago
    Every other UNIX like platform behaves one way (returns after timeout for empty/NULL fd set) and always has, but if you want to pick the interpretation that makes it a non bug in OS X - then you have to agree that it was buggy under OS X between 10.9 and 10.12! Can't have it both ways :) Also whatever you say - no sane OS vendor keeps alternating between different undefined behaviors causing pain for developers. MS, Linux, FreeBSD - AFAIK they all do everything to not break user space. Linus has famously said - if you break a working userspace binary - it's a bug!
    - eridius 10y ago
      > you have to agree that it was buggy under OS X between 10.9 and 10.12 No you don't. Neither behavior has to be buggy. That's what undefined behavior means, that any and all possible behaviors are valid because no specific behavior is defined as correct. > Linus has famously said - if you break a working userspace binary - it's a bug! That's a very hard-line stance, and it means accidents of implementation become guaranteed behavior which can be extremely restrictive down the line. Linus obviously believes that this philosophy is correct for Linux, but that doesn't mean it's correct for OS X.
      - blinkingled 10y ago
        I think this is going beyond reason - not correct for OS X?! What does that mean? It's not just Linux either - MS does the same thing. You don't cause developers and users pain by randomly changing stuff - correct or incorrect to you doesn't factor. If something was working it is a reasonable expectation for any mainstream OS that it will continue to work. If you don't agree with that then your choice - the world hasn't worked that way in a while. It would be one thing if they always consistently returned immediately in poll if you passed NULL but alternating between returning immediately and returning after timeout with no guarantee which OS version will change it again in future - that's madness. Hey but ok - for you I will say it - Apple can do no wrong!