That page doesn't explain why it says kqueue is buggy. All it says is

> most versions support only sockets, many support pipes

That seems to be self-contradictory, especially because elsewhere in the document it says

> usually it doesn't work reliably with anything but sockets and pipes, except on Darwin, where of course it's completely useless

But nowhere on that page can I find an explanation of what's actually wrong with it.

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 (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

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-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.

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.)

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.

> 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.

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.

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!

> 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.

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!

> You don't cause developers and users pain by randomly changing stuff

That's different than the hard-line stance that Linus takes. Either you're deliberately mischaracterizing what's going on, or you don't actually understand what you were referencing.

In any case, just because some API behaved in a particular way in a degenerate possibly-undefined case doesn't mean the OS needs to preserve that behavior in the future. It was probably an artifact of implementation, so if the implementation changes, the undefined behavior may change too. And that's perfectly alright, if it's undefined behavior. Sure, if you are aware of the particular behavior and aware that apps are relying on it, and it's not an undue burden, then it's a good idea to preserve the existing behavior. But that's a lot of "ifs" there.

So you are saying you will feel better if you made the assumption that it is a burden for Apple to stick to one behaviour _and_ you will ignore that a very popular library curl was depending on it and so far had to twice adjust their code. But yeah we will assume undue burden for Apple to keep it working one way.

And No, I am not misunderstanding anything I am sure - as are the libcurl authors! You so far seem to be the only person arguing otherwise with no proof that there is undue burden for Apple while ignoring causing impact s twice for not an obscure library! Ok, I'm done here.

If it's undefined behavior, libcurl shouldn't be depending on it. And the fact that they were bitten by this behavior in the past makes me wonder why they decided to depend on the behavior since then. And I'm definitely not the only person arguing otherwise because what got me thinking that this might be undefined behavior was someone else's comment arguing that. Besides, popular opinion is not what defines a spec, so even if I was the only person arguing this way that wouldn't mean anything.

That is NOT undefined behavior. That is at the most not-clearly-defined behavior that is bounded, with TWO possible outcomes - Apple switches between those (not at runtime - but across OS releases!!) and that's not correct in any sense of the word! Dereferencing NULL/Wild/free()ed pointer (again not applicable to this case - we are not dereferencing the NULL FD set - NULL here specifies empty) is undefined behavior - not specified if that will fail silently or cause you to call a function or trap or a hundred other things - not bounded or in other words without specific choices. Vastly different from either return after timeout or immediately. Do one thing consistently, preferably same as what other UNIXes are doing, or if you do otherwise stick to it. This isn't undefined behavior where code does something and result can be unknown - this is deliberate behavior!

There are more than 2 possible choices if you read the spec as leaving the empty set case undefined. There's 2 choices that are likely to result, but that doesn't mean the implementation can't do something else instead.

> Apple switches between those (not at runtime - but across OS releases!!) and that's not correct in any sense of the word!

Assuming it's undefined, then sure it is. Linus treats accidental implementation-defined behavior as guaranteed in Linux. But Apple only guarantees documented behavior. If something is undocumented, Apple is free to change it. In practice, they try to keep backwards compatibility (even going to such lengths as preserving old bugs for certain apps based on bundle ID), but that doesn't mean they guarantee backwards compatibility for undocumented behavior, or that they're wrong when they change something that affects undocumented behavior.

> This isn't undefined behavior where code does something and result can be unknown - this is deliberate behavior!

Given that the behavior changed, I'm willing to bet it's not deliberate behavior but is an artifact of implementation.

This comment violates the HN guidelines. Please don't post uncivilly again.

Now you're just being deliberately offensive. I do not appreciate you implying that I'm a troll. I've been nothing but honest throughout this whole discussion and have explained my reasoning many times. The fact that you interpret your disagreement with me as proof that I'm a troll is incredibly arrogant.