3 ms·

> XPC is not asynchronous It's been some time since I dug into the internals of XPC, but my assumption was that the underlying protocol is asynchronous, and if

> XPC is not asynchronous It's been some time since I dug into the internals of XPC, but my assumption was that the underlying protocol is asynchronous, and if you do sync calls the wrappers just do the waiting for you. The problem is that it has a tendency to get stuck in some rare cases, where services just don't reply for some reason. Then the sync calls are the worst -- the UI of the app is completely frozen and there's nothing you can do except restart the app. If the problem is with an Apple service (like Apple ID) then the only way to fix it is to restart the Mac and hope it doesn't happen again.

setpatchaddress 5y ago
XPC sync is not in fact async underneath in recent macOS versions. It’s a severe performance pessimization to use async in many cases, because sync propagates thread priority and async often can’t. You don’t seem to have a full grip on the reasons for the intermittent hangs you’re experiencing. Can I suggest two things? 1 Grab a sysdiagnose during one of the hangs and file a feedback report with Apple 2 Use the `sample` command line tool to see what’s actually hanging a particular process for yourself
- newaccount74 5y ago
  Yeah, I've recently done exactly this for one of the hangs. Unfortunately Apple was extremely unhelpful, it took a few back-and-forths with DTS to get a response from someone who even bothered to actually read my bug report. (I just got a few generic replies "please submit an Xcode project" first). But even then they just kept asking me for a way to reproduce the issue, which I couldn't, since it happened on a customers machine, and disappeared after a restart. Even though the issue was reported multiple times over a couple of months by various customers, it took me a lot of time to actually get a usable sample from a customer. But apparently even a sample of the process showing exactly where Apple's frameworks are hanging isn't enough for them to start investigating. I try to report all of the issues I see to Apple, but at some point there's nothing I can do except complain that Apple's frameworks are buggy. The biggest problem with these bugs is that customers always seem to think it's an app bug, and there's nothing the app developer can do except hope that Apple fixes the issue. One early sandbox bug took Apple about 3 years to fix. To be honest I don't even know if they fixed it, it was never mentioned in a changelist, it's just that I stopped getting reports of the issue at some point.
- newaccount74 5y ago
  > XPC sync is not in fact async underneath That's interesting! I thought XPC was a wrapper around async mach messages. Do you have any pointers where I can learn more about this?
  - astrange 5y ago
    When you get to kernel land it is "something async plus a wait"; there's no other way for it to be when the remote task is on a different core. But it's a special wait that the scheduler and other systems know how to benefit from using vouchers/turnstiles/etc. If you look at spindump output you should see it.
- astrange 5y ago
  > 2 Use the `sample` command line tool to see what’s actually hanging a particular process for yourself Don't use "sample" if the issue could be multi-process or in the kernel, use "spindump".

setpatchaddress 5y ago

XPC sync is not in fact async underneath in recent macOS versions. It’s a severe performance pessimization to use async in many cases, because sync propagates thread priority and async often can’t. You don’t seem to have a full grip on the reasons for the intermittent hangs you’re experiencing. Can I suggest two things? 1 Grab a sysdiagnose during one of the hangs and file a feedback report with Apple 2 Use the `sample` command line tool to see what’s actually hanging a particular process for yourself

newaccount74 5y ago
Yeah, I've recently done exactly this for one of the hangs. Unfortunately Apple was extremely unhelpful, it took a few back-and-forths with DTS to get a response from someone who even bothered to actually read my bug report. (I just got a few generic replies "please submit an Xcode project" first). But even then they just kept asking me for a way to reproduce the issue, which I couldn't, since it happened on a customers machine, and disappeared after a restart. Even though the issue was reported multiple times over a couple of months by various customers, it took me a lot of time to actually get a usable sample from a customer. But apparently even a sample of the process showing exactly where Apple's frameworks are hanging isn't enough for them to start investigating. I try to report all of the issues I see to Apple, but at some point there's nothing I can do except complain that Apple's frameworks are buggy. The biggest problem with these bugs is that customers always seem to think it's an app bug, and there's nothing the app developer can do except hope that Apple fixes the issue. One early sandbox bug took Apple about 3 years to fix. To be honest I don't even know if they fixed it, it was never mentioned in a changelist, it's just that I stopped getting reports of the issue at some point.
newaccount74 5y ago
> XPC sync is not in fact async underneath That's interesting! I thought XPC was a wrapper around async mach messages. Do you have any pointers where I can learn more about this?
- astrange 5y ago
  When you get to kernel land it is "something async plus a wait"; there's no other way for it to be when the remote task is on a different core. But it's a special wait that the scheduler and other systems know how to benefit from using vouchers/turnstiles/etc. If you look at spindump output you should see it.
astrange 5y ago
> 2 Use the `sample` command line tool to see what’s actually hanging a particular process for yourself Don't use "sample" if the issue could be multi-process or in the kernel, use "spindump".