
Poll on macOS 10.12 is broken - okket
https://daniel.haxx.se/blog/2016/10/11/poll-on-mac-10-12-is-broken/
======
itp
I can't say I'm surprised. I used to be responsible for the port and upkeep of
a relatively low level product to OS X. It was far and away the most
troublesome platform. We would frequently run into bugs that had been reported
on openradar for years without having been addressed.

Off hand I remember spending the better part of two days trying to understand
a bug that was traced to a coroutine issue -- OS X was just not saving a
required register, known and reported for 5 major versions.

I remember discovering that unnamed semaphores don't work on OS X. Not that
the functions aren't implemented, just that they always return an error.

So I'm not surprised that poll() would be broken, nor am I surprised that it's
broken again.

The only thing that surprised me anymore is how many people continue to insist
to me that OS X (or macOS now, I guess) is a great UNIX. It may be a great
desktop OS.

~~~
matwood
Sierra + the lack of MBP updates has me seriously looking around if I can
switch to Linux for my next setup. The Dell 5500 laptops look nice, and I have
purposely kept my tools as platform agnostic as possible. So far my list of
problems are:

* HiDPI does not seem to work as well on other platforms.

* Lightroom is a pain to run over wine or some other tool (and no, Darktable is not there yet)

* 1Password still has no linux client

* I like the iPhone and do not plan to move away anytime soon

* iOS app builds - not really a problem to keep my old MBP around just for doing builds

I have been using linux for years on the server and I'm really amazed how
short this list has become.

~~~
matt4077
Oh you'll find new entries for the list. Linux on the desktop is nowhere near
macOS. I'm saying this as a huge fan of Linux on the server, who frequently
tries it on desktops.

There is no Linux desktop experience that is consistent, or coherent. You'll
frequently want to use software that happens to be made for the other window
manager, and suddenly you have different keyboard layouts depending on the
window that's active. Toolbars are sometimes on top, sometimes in the window.
Sleep absolutely definitely will never work, unless you muck around in the
kernel for a bit. Then it works but your wifi cuts off when you're playing
music.

Most of design is either created by people who want to punish you for leaving
the command line, or these people who put blinking, nascar-style ornaments
into their water-cooled, wall-mounted, intel-inside-stickered towers.

Oh, and battery life on Skylake is about half of what a Macbook gets.

~~~
Diederich
I've been exclusively Linux as my desktop and laptop, personally and
professionally, since the 1990s, and I manage Linux on laptops and desktops of
some family members. I am very much of a 'back-end', 'server' kind of guy. My
desktop has dozens of 80x24 terminals and a big web browser window, typically
running under [http://www.6809.org.uk/evilwm/](http://www.6809.org.uk/evilwm/)

So, I can't directly disagree with most of what you said on point, except for
sleep/hibernate/suspend. Especially in the last decade, it often works without
any low-level tweaking, and I can get it going in MOST cases without too much
fuss.

In the last 10+ years, my wifi experience on Linux has been very solid, often
more solid than my OSX-using co-workers.

But this is all anecdata.

Though Ubuntu (and to a much lesser extent, some others) have come light-years
toward producing a consistent, coherent Linux desktop experience, it still
lags painfully behind OSX and Windows.

With all of these disadvantages, though, the 'all the way down' reliability
and no-bullshit you get from a Linux desktop (or server) is worth its weight
in gold. It's just that the entry fee is still too high.

~~~
bertiewhykovich
I dunno, man -- I feel like constant user-experience problems, bizarre
hardware issues, and endless configuration tweaking is both unreliable and
bullshit. I often contemplate switching to a Linux system, even if just for a
change of pace, but I can't justify giving up a platform that allows me to get
the vast majority of what I need to do done without waging war against some
other programmer's neuroses.

~~~
nitrogen
It's really about what you're used to using. I tend to have more problems when
I'm using macOS than Linux.

~~~
bertiewhykovich
That's very fair. Most of my non-work computing tends to follow typical
consumer trends, and most of my work computing isn't meaningfully compromised
by running macOS over Linux (now that VMs are usable, at least) -- but I can
imagine that if I depended on applications that don't have clear macOS
equivalents that Linux would seem far more "reliable and no-bullshit" to me.

That beings said, the vast majority of consumers, and I suspect the vast
majority of developers, do not rely on such applications (or their equivalent
w/r/t Windows).

------
StreamBright
Late adopter here. I never update to any new operating system from Apple on
any of my devices what I need to use for production up front. I usually wait
until I absolutely have to upgrade otherwise something does not work, or if I
have evidence that the new OS runs well on the device I am going to install it
on. This saved me a lot of headaches in the last 5-10 years. Given Apple's no
downgrade once you upgraded attitude with MacOS I would say it is extremely
risk to update to any new operating system version. For those who are not
familiar, it is not supported to downgrade MacOS by Apple, they upgrade the
firmwares many of the devices in your Mac during an upgrade and there is no
official downgrade for those. It is possible with hacking, I know, but I would
not risk warranty with such a method.

~~~
riskable
There's risk both ways... By updating you risk breakage. By _not_ upgrading
you risk security issues and increase technical debt (which is a risk
amplifier).

I'd argue that missing out on security fixes is _far_ more risky than any
technical issues you may encounter after an update but I'm a security
engineer.

~~~
StreamBright
Security patches are available for the previous version, the trend is that the
previous 2 versions of OS X receive security updates. Would you mind giving me
an example of technical debt? I am not sure what you mean by that. Just to
confirm, I am not missing out on security fixes at all, I am updated all the
way to the latest version with security patches with the previous version of
MacOS.

~~~
Tepix
There are a ton of security fixes for macOS sierra. These fixes have not been
published for older releases of OS X yet. Apple wants people to upgrade.

~~~
pritambaral
But is Apple stupid/naive/childish enough to hold security fixes to ransom?

~~~
nchelluri
I'd guess not "ransom", but not enough resources allocated to backport fixes,
along with a lack of incentive since they fixed them already in the gold
standard New Version.

~~~
pritambaral
> not enough resources allocated to backport fixes

Which is just silly for someone like Apple

> a lack of incentive since they fixed them already in the gold standard New
> Version

That is _not_ how security works. Again, it is just silly for someone like
Apple to believe only the latest release needs security fixes.

~~~
nchelluri
Oh, I completely agree. I've ranted about this before; I like to use old
versions and be a late adopter after all the kinks get worked out. I'm just
saying maybe it's more due to a (possibly negligent) misplacement of
priorities than to outright malevolence for non- or slow-upgraders.

"We're Apple... everyone always uses the latest versions of our stuff..."

------
bangonkeyboard
10.12's poll() is also newly broken in another way. When called with certain
combinations of descriptors, it will block forever, causing an application
hang: [https://github.com/mpv-
player/mpv/issues/3530#issuecomment-2...](https://github.com/mpv-
player/mpv/issues/3530#issuecomment-250045418)

------
qwertyuiop924
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
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
Well, of course things will break in development, that's to be expected. But
once it's been released...

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

------
nxc18
It sure would be nice if macOS worked as well as Apple was promising a few
years back.

My MBP is so buggy as it is with El Cap that I prefer to use a cheap surface 3
for anything other than dev work.

Every time Apple releases a macOS update I'm left to decide between the bugs I
already experienced that might be fixed and the mountain of bugs that are
surely hidden in the new update.

~~~
wlesieutre
I used to have a Surface Pro 3 and the wifi on that machine was mental. I know
people have been complaining about wifi reliability on Apple's computers for
years now, but the Surface was really something else.

Every couple of weeks they'd put out a patch that claimed to fix the wifi, and
while it did get better, it was never as good as it should have been. I live
in a 1-bedroom apartment with an 802.11ac router and all of my other devices
work fine. The router's off at one end of the apartment where the coax comes
in, but I'm never more than 25 feet away from it.

~~~
stinkytaco
I had the same issue on my Surface, but Windows 10 basically fixed it. Of
course, that was a year after I bought it.

I've heard here and talked to a number of professionals that do not use Linux
because they want something that "just works". But if I really sit down and
catalog my issues, Linux can be a headache to set up, but once it's working I
rarely have issues. Part of that is researching the right hardware, so I guess
it's not the plug and play of proprietary platforms, but it works.

~~~
wlesieutre
Wifi was definitely better under 10. The random keyboard disconnections on the
other hand... those never got fixed. Maybe it was a hardware problem with the
magnetic connector and pogo pins.

The last piece of productivity software I wanted on Linux was just released
recently (Substance Designer), so I'm seriously considering a dual boot. Have
to keep Windows around because it's my gaming machine, but I'm a bit sick of
having software updates shoved down my throat at inopportune times.

What pisses me off the most about W10 is that it makes you pick "active hours"
when it won't install updates, but it's a 12 hour maximum and it's the _same
every day_. As if my home computer's usage pattern on Monday-Friday is going
to be the same as the weekend.

------
blinkingled
Welcome to Apple QA. Where system call return values are worthless and radar
reports don't matter!

------
coldpie
One of our devs also found that getdirentries returns a bogus too-large value
when given a buffer much larger than needed to store the actual data on
return, and fills the remainder of the buffer with 0. This caused an infinite
loop in our code, as we continually processed empty strings. This behavior is
new in 10.12.

~~~
gre
getdirentries() is deprecated as of 10.6 because it doesn't work with 64-bit
inodes, according to the man page. The manpage recommends using readdir().

------
Keyframe
Lots of stuff on macOS gone weird / mental. Try to set thread affinity, for
example. Look at their source in /usr/include/mach/thread_policy.h under
thread_policy_set and thread_policy_get

~~~
valarauca1
Lots of stuff on macOS gone weird / mental. Try to allocate large blocks of
memory in a dynamically loaded function. The pointer you get back is a raw
_non-virtual_ pointer, then you need to use non-posix calls to map that region
into your process's virtual memory space.

~~~
chillaxtian
could you expound on this? which syscall exactly are you making?

~~~
valarauca1
POSIX != SysCalls

Libc (or the various other libs that compose libc) are not necessarily system
calls, often they are wrappings of severals.

I'm talking about the `dlfnc.h` interfaces.

~~~
slrz
Are you saying that when you call dlsym(3) on OS X you get back a non-null
pointer to memory that is _not_ mapped inside your address space? That can't
be, right? So where does your "weird" pointer actually come from and how is it
connected to the allocation of huge blocks?

~~~
valleyer
Seconded. Please post a test case that shows this failure.

------
ankurdhama
In the specs of the poll function I don't find anything that says if you pass
NULL as the fds then also it will wait for specified timeout. Am I missing
something?

"If none of the defined events have occurred on any selected file descriptor"
\- This statement is not same as passing NULL.

~~~
groovy2shoes
Passing NULL is treated like passing an empty fd set. If there are no file
descriptors to check, then "none of the defined events have occurred on any
selected file descriptor" is trivially true. The same would hold for non-empty
fd set and no defined events, I'd imagine.

~~~
ankurdhama
It is kind of tricky to define this situation formally. Much like if a
statement says "Given a list of numbers" than does empty list denotes a list
of numbers? There are arguments for both - yes it does and no it doesn't - but
the only way to select any one argument over other without conflict depends on
additional constraints in the definition like saying "Given a list of numbers
where the minimum length of list is 1".

~~~
groovy2shoes
If it is an empty list of numbers, then sure, it denotes a list of numbers.
Luckily, we have type systems that enable us to tell empty lists apart :)

------
hellofunk
The OCaml system no longer works on macOS either, installation is totally
wacked out. A fix is being worked on.

~~~
tempodox
Thanks for the warning. I put macOS 12 installation on hold for more
superficial shortcomings. This one would have taken me a bit longer to find.

I have adopted the practise of installing new OS releases on a separate test
partition first. Blindly updating the main system can be a really bad trap.

------
slyrus
I saw the headline and thought: "Definitely voting yes on that poll!" but then
I realized it said something else. Still...

------
mwcampbell
I wonder why libcurl even bothers with poll on macOS when there's kqueue.

~~~
blinkingled
Less platform specific code (kqueue is osx/bsd specific IIRC)? And it's not
like libcurl needs the scalability of kqueue.

Bonus stink -
[http://pod.tst.eu/http://cvs.schmorp.de/libev/ev.pod#OS_X_AN...](http://pod.tst.eu/http://cvs.schmorp.de/libev/ev.pod#OS_X_AND_DARWIN_BUGS)
\- kqueue has been buggy and Apple switched poll to use kqueue in 10.5.6!

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

~~~
blinkingled
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
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...](https://github.com/carllerche/mio/issues/163#issuecomment-98813582)
\- 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
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
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
> 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
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
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
> _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
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
> _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.

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

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

~~~
blinkingled
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!

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

------
pmontra
No unit tests on syscalls at Apple?

~~~
raverbashing
You can't unit test a syscall.

But it needs to be a regression or integration test

(However I can understand people thinking "ah if you're polling nothing then
it immediately returns" instead of looking at the spec)

------
Matthias247
Is this error only happening when the polled set contains no file descriptors
at all?

I personally would not have guessed that this usage is valid at all, since it
would always for the timout. If no timeout is specified there's then even the
question if it should wait infinitely (makes no sense but matches the normal
poll-without-timeout behavior) or not at all.

~~~
noselasd
Yes. The timeout is specified, but no file descriptors is given. (so calling
poll() behaves like sleep/usleep ).

This behavior is explicitly described in posix, worked prior to OSX 10.12, but
behaves differently as of OSX10.12

~~~
deathanatos
> _This behavior is explicitly described in posix_

Where? Here's the [POSIX specification of poll][1], for reference. Nowhere in
there can I find that it _explicitly_ specifies the behavior of an empty-set
poll. The only really relevant paragraph, with relation to the _timeout_ arg
is this one:

> _If none of the defined events have occurred on any selected file
> descriptor, poll() shall wait at least timeout milliseconds for an event to
> occur on any of the selected file descriptors. If the value of timeout is 0,
> poll() shall return immediately. If the value of timeout is -1, poll() shall
> block until a requested event occurs or until the call is interrupted._

But "if none of the defined events have occurred" isn't really evaluable when
there aren't any defined events in the first place; the answer is undefined
because the question is wrong. Thus, it seems to me that this behavior is
undefined, as far as POSIX is concerned.

(I wonder if this could be rephrased as, if ∃ fd∈∅ where none of the defined
events have occurred on fd, then poll shall wait _timeout_ …; this if is false
(not undefined), so is should not wait the timeout. But then, the standard
leaves us wondering what it _should_ do, if not that. I think this
reinterpretation depends on equating "any" with "at least one", though.)

(Having poll wait the timeout when passed the empty set certainly seems
_useful_ , but whether or not that's _standard_ is a different question.)

[1]:
[http://pubs.opengroup.org/onlinepubs/9699919799/functions/po...](http://pubs.opengroup.org/onlinepubs/9699919799/functions/poll.html)

~~~
lmm
> "if none of the defined events have occurred" isn't really evaluable when
> there aren't any defined events in the first place

It absolutely is evaluable. If there are no defined events then none of them
has occurred. There's nothing weird or undefined about that; the empty set is
empty.

~~~
duaneb
> If there are no defined events then none of them has occurred.

No no, all (certainly any!) of them occurred.

~~~
Matthias247
Yeah, it seems a little bit like arguing whether 0/0 is 0 or infinity without
exact specification.

While I would agree that the specification the poll case would favors sleeping
I would still guess that it's pretty much undefined behavior as it's not a
normal use-case to wait for nothing and would not rely on it.

I don't see why a pure sleep behavior of poll would be wanted anyway, as it
makes the eventloop unresponsive until the next timeout - which is normally
not wanted in an eventdriven application. Normally I would always have at
least one filedescriptor for eventloop wakeup (eventfd, signalfd, self-pipe,
...) in the poll set.

~~~
gpderetta
A pure sleep is exactly desirable when poll is coupled to a userspace timer
queue. In this case you want to block until the next timer expires or the next
io event, whatever come first. It is a fundamental building block of many
event based applications.

~~~
Matthias247
That's totally right, forgot about that one. Probably used timerfd too much in
the past :)

------
torrey_braman
Thought we were going to vote on whether or not we agree that macOS is
broken.. I was ready to vote for "Yes". =/

------
tim333
cache:
[http://webcache.googleusercontent.com/search?q=cache:ByQB7vd...](http://webcache.googleusercontent.com/search?q=cache:ByQB7vdOuhgJ:https://daniel.haxx.se/blog/2016/10/11/poll-
on-mac-10-12-is-broken/&num=1&hl=en&gl=uk&strip=1&vwsrc=0)

------
jibcage
Mirror anywhere?

~~~
rkcr
The page loaded after a while, so I've got you covered with a gist:
[https://gist.github.com/dlew/781f4bfac391ab1b64ad383c979ac38...](https://gist.github.com/dlew/781f4bfac391ab1b64ad383c979ac38f)

~~~
davidcollantes
Do you have an automated way to do this?

------
coldcode
Yet another reason not to ship 4 OSs the same month every year.

~~~
pvdebbe
Four?! MacOS and iOS I know, what are the other two?

~~~
italophil
tvOS and watchOS

~~~
pvdebbe
Thanks. watchOS I know by name, tvOS is totally new to me. Funny that it has
to be its own thing.

~~~
Razengan
TVs inherently require a different UI and control mechanism than computers or
handheld touchscreens. It's more or less a reskin of iOS, pretty nice, and you
can cross-compile/cross-purchase iOS/tvOS apps fairly seamlessly.

I'm glad Apple chose to develop a different OS for each class of device,
unlike say, Microsoft's insistence on the one-size-fits-all approach — it's
what made the iPhone popular in the first place.

~~~
valarauca1
>TVs inherently require a different UI and control mechanism than computers or
handheld touchscreens. It's more or less a reskin of iOS, pretty nice, and you
can cross-compile/cross-purchase iOS/tvOS apps fairly seamlessly.

This isn't what an OS is. It is about 10 levels of abstraction below this. It
handles managing virtual memory, IO, networking, process switching, processor
interrupts, threading. All the low level nitty-gritty hardware details you
need to worry.

These tasks are fairly generic this is why Linux can run on Smart Phones,
Laptops, PC's, Watches, and Super Computers.

~~~
cyphar
> >TVs inherently require a different UI and control mechanism than computers
> or handheld touchscreens. It's more or less a reskin of iOS, pretty nice,
> and you can cross-compile/cross-purchase iOS/tvOS apps fairly seamlessly.

> This isn't what an OS is. It is about 10 levels of abstraction below this.
> It handles managing virtual memory, IO, networking, process switching,
> processor interrupts, threading. All the low level nitty-gritty hardware
> details you need to worry.

> These tasks are fairly generic this is why Linux can run on Smart Phones,
> Laptops, PC's, Watches, and Super Computers.

You're talking about the kernel Linux, not about an operating system. An
example of an operating system is GNU/Linux, which includes much more than
just a kernel.

------
meelooo
clicked the link and got "Error establishing a database connection". Not sure
I can trust the source ;-).

~~~
mrmagooey
This is a common error message for a number of CMS's (in this case probably
WordPress) when overloaded, and shouldn't reflect upon the validity of the
source.

------
Esau
"poll() is defined by POSIX and The Single Unix Specification"

This makes me wonder if Apple really earned the Unix certification. If it
didn't, then the Open Group should be ashamed.

------
BillyParadise
I misread it. I thought this was a poll on whether Sierra was broken. My vote

All I know is I'm getting 50% less battery time this week.

Oh, and sqllite-ruby seems to be a bit grumpy.

