What the hell, Apple?
Presumably at the same time breathless and misinformed comments stop being posted to HN.
In this case returning EINTR is documented behavior and the bug is thusly on PostgreSQL not handling it (correctly or at all).
It is true that typically Apple doesn’t care if they change things within the limit of the specification and 3rd party applications fail. That’s why they release beta versions.
Almost any syscall can return EINTR, but in practice, for all previous OSes, it has been reserved for those that can hang for an undetermined amount of time -- that is, anything from the network. Local I/O should complete in a bounded amount of time, so that kind of sleep is usually implemented as uninterruptable.
There's one highly relevant edge case: NFS. NFS looks like local I/O, but if the NFS server goes away, what do you do? Traditionally, the process just hangs in the hope that the server will come back, which leads to the dreaded issue of processes being stuck and unkillable. On Linux, can add the “intr” flag to the mount (possibly via a remount) to allow signals to interrupt the syscall and break the deadlock -- but then you break a ton of software, because, again, EINTR on local file I/O is unheard of.
Probably was a hard choice to make for Apple too. Should a thread be frozen for an undetermined amount of time while an antivirus does the check?
Yes, certainly it should.
It certainly does on other OSes and on previous versions of this one?
Do you really want to rewrite all existing software because it would be nice in 0.01% of cases that a thread is not "blocked" by an antivirus on file open, and can actually do something else, and that not on a specialized API but on good old syscalls? From a system design point of view that makes no sense.
No. First, it's not a rewrite but a bugfix patch. Second, you will want this fix because open can return EINTR. It's documented. The code (postgresql in this case) is wrong. It should be fixed. simple.
Apparanty it was on an open() call on local file which is certainly ... unusual
https://www.postgresql.org/message-id/20210115210548.zfbnulf...
open() was documented to be capable of returning EINTR. The Postgres team chose not to write code to handle that case. Now they’ll have to write code to handle that case, or drop support for macOS. That’s life on macOS. They’ll fix it or they’ll drop macOS support.
Keep up or walk away. Repeatedly complaining about macOS being a moving target will not change Apple’s direction. Boycotting it will not either. Either target the platform on the terms provided or drop support for it.
But for the sake of HN, please just let it go. If you don’t want to be macOS hackers, then just don’t be, and move on to another post. Let those of us who do want to be macOS hackers contribute value to HN instead, by talking about the minimum-viable workarounds and how to find other broken code in Homebrew, instead of driving us away. (For example, there’s an obvious way to solve this that doesn’t require disabling SIP.)
The recurring outrage and the reposted miserable viewpoints framed as ‘questions’ with nothing new or curious in them makes HN look immature and unprofessional. Everyone that y’all might have swayed has already been swayed, everyone that hasn’t been swayed has stopped commenting about it, and all that’s left is the echo chamber complaining to itself.
The development experience on Linux is sublime. I feel so much more productive. On the flip side, it took me two or three weeks to customize and setup the way I like it.
In the end, it was worth it.
I read all of these posts and think: I'm so glad that I dropped OSX support. A lot less entitlement and a lot less work :)