It's probably related to the "Just Works" pairing method that DOESN'T happen in those cases I am seeing the alert. Got some heavy-wight workaround idea sketch: split the app into two with the second one being background only process. Specify CBConnectPeripheralOptionNotifyOnConnectionKey / CBConnectPeripheralOptionNotifyOnDisconnectionKey, CBConnectPeripheralOptionNotifyOnNotificationKey keys being false and make the "connect" call from there. Then somehow (XPC?) communicate data back to the main app. There must be an easier way!

This works reasonably well. However, is there a better approach? The two different devices with the same txPowerLevel could have different RSSI at 1 meter values (besides txPowerLevel is optional).

I was thinking of setting up a signal handler that does Thread.current and assigns the result somewhere (e.g. to a global variable). And then pthread_kill(...) to invoke that signal handler on the thread in question. Do you think this won't work? All the mentioned API's included signal and pthread_kill seem to be supported.

This is not safe I see, thank you.

Anyone knows?

What was the best approach at the end of the day? (for macOS / iOS + appstore)

Basically I wanted to have the (short) thread numbers compatible with those shown by Xcode's CPU panel. I can get the thread number from NSThread already, but not from a pthread_t.

What’s you’re high-level goal here? Why do you intend to do with these processor control ports when you get them? I want to get the CPU usage per processor / core, similar to Activity Monitor's "CPU Usage" window.

I see. Is there a path that doesn't involve privilege escalation? I am thinking of using task_threads + thread_info (with THREAD_BASIC_INFO to get cpu_usage) and somehow determine which processor/core the thread is currently assigned to (†) and then accumulate cpu usages per processor/core. This will only account for threads in the current app but for my purposes this would be enough. (†) - pthread_cpu_number_np doesn't return sensible results for me.

Let me try: let queues = (0 ..< 200).map { i in DispatchQueue(label: "queue-\(i)", serial or concurrent) } queues.forEach { queue in queue.async { while true { // doing something lengthy here is Thread.current unique? In other words was a dedicated thread allocated for this queue? or could a single thread serve several queues? } } } In my tests so far a unique thread is allocated per queue.

My fear was that while one queue's work item is still in progress the associated thread could be used somehow to run the other queue's work item.

Right... I'm still curious though how to properly read this specific part of the documentation: For all other address families, it contains a pointer to the struct ifa_data (as defined in include file <net/if.h>) which contains per-address interface statistics. as I do not see "struct ifa_data" anywhere...

concurrentPerform is a class method that has no queue parameter, so the wording in the documentation about "If the target queue is a concurrent queue..." is bogus, not just unclear.

Thank you! So there was no way indeed to download folders in there?! 🤣

I see (and will file the bug). I was a bit nervous running a very similar code to yours on my computer and making far fetching conclusions about what to expect in the ifa_data field in the wild: the doc is buggy, but because it's buggy it's hard to tell what is correct in it and what's not (what to trust and what not). The most conservative approach would be: "if it's buggy – don't second guess it and don't trust it at all". different OS versions / or (Apple) platforms might do things differently, and what happens on my device might not be the whole story. special conditions on user devices (wifi/cellular? p2p? network link conditioner? vpn tunnels? usb wifi dongles?) might mess things further. Some (in fact strong [1]) reassurance I'll have when I see the actual source that populates ifa_data field. Could you please point me to the right place if that's publicly available? [1] normally it's unwise to jump to conclusions based on what's in the source: normally the doc is king and implementation could be changed on a whim... In this particular case, though (1. doc is buggy, so definitely not king, 2. the API is ancient, so hardly ever change (significantly) 3. Hyrum's law is at play and it makes implementation changes even less likely) the source code deemed to be the best "source of truth".