4 ms·

You can find many bug reports referencing OS X kqueue brokenness - however if you want to get to the details of what's wrong with kqueue impl on OS X - you will

You can find many bug reports referencing OS X kqueue brokenness - however if you want to get to the details of what's wrong with kqueue impl on OS X - you will have to do that yourself - test out various use cases, look at libev source code and try to get it to use kqueue on various OS X versions, get it to pass all tests - iow lot of work. It seems to be acquired wisdom to ignore kqueue on OS X for many OSS projects. As this thread also shows it (poll which use kq) worked on previous version but broke on Sierra which alone seems to be enough to ignore it. Here is a thread with sample code having kqueue issues - https://discussions.apple.com/thread/4783301?tstart=0 https://discussions.apple.com/thread/4783301?tstart=0 (Note: I haven't seen that code myself - it might as well be buggy itself but you can use it for your tests as a starting point I suppose.) Edit: User DerekL also reports running code that illustrates the bug on latest iOS version - https://news.ycombinator.com/item?id=12687527 https://news.ycombinator.com/item?id=12687527

eridius 10y ago
Poll may be implemented using kqueue, but that doesn't mean that a claimed bug in poll means kqueue is buggy. Specifically, that HN comment you're linking to is talking about testing poll, not testing kqueue, so it's irrelevant. As for that discussions post, there's no replies at all so there's no indication as to whether anybody's analyzed it to find out if there's a bug in that code. That post alone is not remotely sufficient to claim there's a bug in kqueue. Also, after a fairly cursory examination, I've already found a case of uninitialized data being passed to kevent() (specifically, the code puts a struct kevent on the stack, fills in 3 fields, and then passes that to kevent(), even though this leaves 3 fields undefined; see line 169). The other really funny thing this code does is it updates a kqueue from one thread while it's being waited on in another thread. I don't see anything in the manpage about thread-safety, and a comment thread on mio suggests that it may not be safe to do this (https://github.com/carllerche/mio/issues/163#issuecomment-98813582 https://github.com/carllerche/mio/issues/163#issuecomment-98... - one person says it's not safe, other people say it is safe with epoll, it's unclear whether this is actually true and whether kqueue is safe or not). If it is not in fact safe to update the kqueue from one thread while waiting on it in another that would certainly explain the missing events.
- blinkingled 10y ago
  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

Poll may be implemented using kqueue, but that doesn't mean that a claimed bug in poll means kqueue is buggy. Specifically, that HN comment you're linking to is talking about testing poll, not testing kqueue, so it's irrelevant. As for that discussions post, there's no replies at all so there's no indication as to whether anybody's analyzed it to find out if there's a bug in that code. That post alone is not remotely sufficient to claim there's a bug in kqueue. Also, after a fairly cursory examination, I've already found a case of uninitialized data being passed to kevent() (specifically, the code puts a struct kevent on the stack, fills in 3 fields, and then passes that to kevent(), even though this leaves 3 fields undefined; see line 169). The other really funny thing this code does is it updates a kqueue from one thread while it's being waited on in another thread. I don't see anything in the manpage about thread-safety, and a comment thread on mio suggests that it may not be safe to do this (https://github.com/carllerche/mio/issues/163#issuecomment-98813582 https://github.com/carllerche/mio/issues/163#issuecomment-98... - one person says it's not safe, other people say it is safe with epoll, it's unclear whether this is actually true and whether kqueue is safe or not). If it is not in fact safe to update the kqueue from one thread while waiting on it in another that would certainly explain the missing events.

blinkingled 10y ago
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.