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...

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.

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.

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.

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.

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 was the best approach at the end of the day? (for macOS / iOS + appstore)

Anyone knows?

This is not safe I see, thank you.

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 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).

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!

No, that doesn't work: the side panel slides and partially obscures the main panel. For the record: the newer NavigationSplitView + navigationSplitViewStyle(.balanced) does work correctly on my plus sized device.

No. I mean, it’ll probably work, but it’s relying on implementation details that could change. In a way it feels even safer to fork in pure Swift app's main.swift file so long as this is done as the very first thing. In C++ app globals' constructors could create threads, mutexes, call malloc and whatnot before (and during) the app hitting main(). I encourage you to run a performance test Indeed fork is not faster than posix_spawn, each took about 120 µs in a simple app. (I forked/spawned 1000 processes for accuracy).

This is the current formula I'm using: let n = 2.0 let distance = pow(10, Double(txPowerLevel - 12 - 62 - rssi) / (10 * n)) Here 12 was the txPowerLevel reported from one test device of mine, and -62 was approximate averaged rssi level at 1 meter distance from that test device. Will give this a test in a field to see how well it goes.