Re: BUG #16827: macOS interrupted syscall leads to a crash

Previous Topic Next Topic
classic Classic list List threaded Threaded
1 message Options
Reply | Threaded
Open this post in threaded view

Re: BUG #16827: macOS interrupted syscall leads to a crash

Joachim Gehweiler
Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> writes:

> Andres Freund <andres(at)anarazel(dot)de> writes:
> > Tom, all, this seems like a serious problem likely to become more
> > widespread. I don't really know how we can reasonably address this
> > short-term, adding EINTR handling to all the places that don't yet have
> > it (and ensuring that it stays that way) seems like it's a lot to backport.
> The only idea that comes to mind is to invent a wrapper for open
> (and other affected syscalls) that adds a loop-on-EINTR. Ugly,
> and it would not fix third-party extensions until they're recompiled.
> My inclination is to regard this as something that's Apple's problem,
> at least for now. Perhaps they'll realize what a disaster it is.
> (OTOH, they've proven pretty mulish on making SIP usable…)

I would strongly vote to go for the loop-on-EINTR wrapper for open that you’re
suggesting, maybe also add a switch for it to the configuration with default ON
for macOS and OFF for all other platforms, for the following reasons:
- the change that Apple made is not a "bug by accident“ but a design decision,
  and Apple is known for not reverting design decisions, no matter what chaos
  they imply (just recall the disaster that rewriting the USB stack caused 5 years
  back, rendering thousands of USB devices useless; especially in the music
  production business it’s the same procedure every year that several
  companies are forced to provide hot fixes to make their software usable again)
- though I agree that it’s a no-go to introduce such a breaking change, to some
  extent there seems to be a reasoning behind it: some antivirus products are
  really slow on certain files (big zip files containing thousands of html files, e.g.
  browsable html-ified documentation, easily can take dozens of minutes to
  scan). So Apple might argue that their change ensures the systems to stay
  responsive when antivirus is failing. This makes it less likely that Apple will
  revert their change

   Joachim Gehweiler