bpo-28087: Detect broken poll() on macOS Sierra #1426
Conversation
|
@Haypo, thanks for your PR! By analyzing the history of the files in this pull request, we identified @akuchling, @tiran and @warsaw to be potential reviewers. |
On macOS, check for broken poll() at runtime on macOS Sierra 16.0.x-16.5.x. Disable select.poll() (remove select.poll) if poll() is broken. Reenable select.poll() tests in test_asyncore and test_eintr on macOS.
|
Removing Given the actual underlying poll bug it might be possible to hide it from Python developers by having our poll implementation add a dummy fd to the call and hide that from the results we give. I hate that though as it decreases the ire against Apple. But it would save the rest of the Python world time and prevent kicking anyone who wants their code to run on MacOS back to the 1990s. |
|
I am not interested to workaround the same bug in all code using poll().
Especially, I don't want to touch the old and legacy asyncore module which
has a weak test suite.
I also dislike using a dummy FD. It took months to identify and fix all
issues caused by the hidden (cached) os.urandom() FD. That's why I was
super motivated to use the new FD-free getrandom() (and then work on the
painful PEP 524).
Removing select.poll() on select initalization if a runtime check says that
it's broken is not something new, I just extended existing code.
poll() offers a well known contract (behaviour), which is not respected by
macOS. Just use select() in that case. It's just a few macOS releases, I
hope that it will be fixed soon.
Modern network code should use selectors or even asyncio and so use kqueue
on macOS. It seems like poll() is just emulated on top of kqueue.
|
|
Understood. See my update in https://bugs.python.org/issue28087. I suspect we do not need to fix anything here as Apple appears to have actually fixed it and shipped the fix. |
|
We shouldn’t be removing the ability to use the POLL syscall from OSX. It still does what it’s meant to, but part of it’s behaviour has changed. We know that it ignores the given timeout now, and we can factor that in.
It’s not worth disabling it, when we know why it’s like this, and can inform those who’re using it about the issue. However, this change is not POSIX compliant, although I never think Apple cared all that much.
For the POSIX page on POLL, look here: http://pubs.opengroup.org/onlinepubs/9699919799/ <http://pubs.opengroup.org/onlinepubs/9699919799/>
Actually, after doing some digging, I'm guessing that Apple is also not sure what's going on, or are just doing the usual, not updating documentation thing, as all current docs say that it should function as expected. We will want to work out a fix for previous versions at the very least, as we should avoid breaking pre-existing programs where possible. Apple does appear to have made a fix, but from what I gather, if it fails to successfully register all the FD's, it'll still return prematurely. May or may not be a problem. We should also work something in-case Apple does something like this again.
Many Thanks,
Ennis Massey
[email protected]
|
|
It was decided to not blacklist specific macOS versions, but just expect that users upgrade to the latest version which are now fixed. So I abandon my change. |
5 participants
On macOS, check for broken poll() at runtime on macOS Sierra 16.0.x-16.5.x.
Disable select.poll() (remove select.poll) if poll() is broken.
cc @MicroTransactionsMatterToo.