I've tagged the thread "macOS", which I hope is the correct way to indicate these things. I'm not specifying the data protection keychain (though I know it's possible with a query dictionary). These keys could be provided from any source to this code, which is part of the issue. Is there a good way to check if a SecKey in-hand came from a particular source? Given the risk of an operation on an item becoming trapped in user authentication (if running in a context where that is possible), it seems like a good idea to be able to preflight and return an error code early regardless of source, item type, or usage. If it helps, assume the System keychain is involved here. I didn't realize kSecUseAuthentication* might be data-protection-only.

kSecUseAuthenticationUIFail(deprecated) and kSecUseAuthenticationUISkip don't actually seem to work with passwords (probably other secrets too) in Monterey 12.5 FB11153260 The old API still works though.

We tried restructuring it this way and figured out part of the issue, you can't deliver or enqueue input or messages of any kind until markReady() (they must be completely consumed), and otherwise that will stall the framer. In the case of TLS any input will be fed into the handshake, corrupting it, and zero-length (with the content stashed in a message) will stall with complete set to true or false. Is there any way to provide this information back to the connection's receive message handler without triggering this? It seems reasonable that framers should be able to pass this information back (return codes, message text, etc) (after markReady() if necessary), in case of either success or failure. The framer shouldn't have to be completely "silent". There's the very recent Options subscript, but that doesn't seem to be a good fit semantically.

As a kind of postscript, we've adjusted or rewritten all algorithms as necessary to avoid stalls (like using dispatch_group_wait), and the issue seems to affect all clients of GCD in-process. Relaunching the app temporarily resolves the issue, but it's still unknown. Making our calculations "stall resistant" isn't ideal, but we haven't heard back at all. It looks like we have to set a watchdog on the app and if triggered pause, save, relaunch, load, and continue until there's something more to work with.

After replacing psort_r with a dispatch_apply-based version we're calling "wpsort", it looks like the stall can still occur, but in other ways. A completely new dispatch_group running on a global queue fails to notify, and it looks like the whole app effectively goes single-threaded, as far as GCD is concerned. It's not the old days with +[NSThread isMultithreaded], but I don't know what could cause GCD to fail to spin up new worker threads suddenly, after more than two hours of computation. It seems to be related to low CPU utilization before the threads become limited, and somehow to the M1 Ultra MacStudio, but this is unusual.

It looks like the internal state of the queue is smashed when this happens. If the dispatch_group_wait is allowed to exit early then dispatch_barrier_sync is called on the same queue, it will wait forever. It may be related to low overall CPU usage, but I'm not sure how. It always seems to take a while (a couple of hours of continuous use) before the issue occurs. Never seen it on Intel or single-chip Apple Silicon

Is it possible this is caused by the Ultra putting certain cores to sleep and that the queue has work assigned to those cores? This seems to happen only with smaller problems (core usage is <= 4 of 20), so opens the possibility that parts of the chip are asleep. I suppose another one is cache coherency between the chips, that the call to "wake" the queue to finish the work "in-flight" is missing. GROUP_FAIL <OS_dispatch_queue_concurrent: QUEUE_NAME[ADDR] = { xref = 1, ref = 9, sref = 1, target = com.apple.root.default-qos[ADDR], width = 0xffe, state = 0x00000c1000000000, in-flight = 4}> <OS_dispatch_group: group[ADDR] = { xref = 1, ref = 2, count = 4, gen = 0, waiters = 1, notifs = 0 }> NORMAL_OPERATION <OS_dispatch_queue_concurrent: QUEUE_NAME[ADDR] = { xref = 1, ref = 1, sref = 1, target = com.apple.root.default-qos[ADDR], width = 0xffe, state = 0x0000041000000000, in-flight = 0}> <OS_dispatch_group: group[ADDR] = { xref = 1, ref = 1, count = 0, gen = 0, waiters = 0, notifs = 0 }>

Not exactly. I have the patches for both, but I'm looking for comments on the use of dnsextd (hopefully from someone in the networking group) on its viability with recent versions of BIND. Also their thoughts on the overall scheme, like relying on the TSIG implementation in macOS for secure record updates. FB10279468 I realized I didn't reference the BIND documentation section 4.2.28.4 Dynamic Update Policies (the external option), which is what's planned.

Looks like building 1557.120.7 from the GitHub releases is pretty different, the latest doesn't have an Xcode target for dnsextd. The patch is much smaller, but the Makefile doesn't collect the conf, man page, launchd plist and executable and put them in an appropriate structure. dnsextd.txt