Hello,
I have a .app NSApplication which is ran as a LaunchDaemon, in it's lifecycle I never call any AppKit functions (I start it with CFRunLoopRun). (mentioned on this post as well).
I intercept a couple of signals using signal(s) in order to trigger CFRunLoopStop(CFRunLoopGetCurrent()) to do some cleanup.
This LaunchDaemon has the purpose of providing VPN connectivity, as such I call connect functions that trigger the "Add VPN configuration" dialog (I can't provide extra details about this, as I integrate another SDK so I'm not sure what happens under the hood) and I noticed that whenever it is displayed, after allowing it, during the lifecycle of the application when it's time to send the signal, the signal isn't received.
I tried re-adding the NSApp callbacks in order to investigate, but it looks like those aren't called as well.
I'm interested in knowing more about this scenario and what happens... I couldn't really find information about this dialog...
Thanks!
As I said in your previous thread, you are seriously off in the weeds here. If you’re building a daemon, it’s not safe to link with AppKit.
As to what’s happening in this specific case, it’s hard to say. The nature of unsupported things is that they generate undefined behaviour. Quoting myself here:
Some of them show up immediately, and some of them lurk, waiting to cause you grief as the system evolves.
I recommend that you rework your product based on the architecture I outlined in that other thread. If you continue down your current path, you will continue to experience weird problems and there’s not much we can do about that.
Share and Enjoy
—
Quinn “The Eskimo!” @ Developer Technical Support @ Apple
let myEmail = "eskimo" + "1" + "@" + "apple.com"