我正在 MAC 操作系统上开发一个应用程序。它有两部分——一个 UI 元素和一个守护进程(需要连续运行并且必须在被杀死后重新启动)。目前我正在使用 launchctl 重新启动守护进程。
但是还有一个问题。我需要应用程序的两个部分相互通信。为此，我使用分布式对象进行相同的操作(如给定的 here )。但是，当我使用 launchctl 启动守护程序时，这不起作用。有人能建议一些替代方案吗？？？
最佳答案
我使用 NSDistributedNotifications 在一个应用程序中很好地处理了这个问题，即使在 10.7 上也是如此。您必须自己进行握手，因为这可能会造成损失(即包含 ack 通知并在超时时重新发送)。这种方法的一个副作用是，如果有多个客户端正在运行(特别是在快速用户切换的情况下)，那么所有客户端都会收到通知。对于这个应用程序的特殊情况来说，这很好。实现起来也非常简单。
对于另一个应用程序，我使用两个 FIFO。服务器向其中一个写入并从另一个读取。客户则相反。当然，您也可以使用网络套接字来实现相同的目的。我倾向于更喜欢 FIFO，因为您不必处理锁定网络套接字的问题。
也就是说，您在 launchd 下使用分布式对象时遇到什么问题？您是否只是在 10.7 上看到问题(它更改了 launchd 上下文的规则)？
您是否使用 launchd 在访问端口时延迟加载守护进程(这是正常的方法)。您是否考虑过使用启动代理而不是启动守护程序？
<小时/>编辑:
啊...引导服务器。是的。您需要在正确的引导上下文中执行事物才能与它们对话。登录 session 的引导上下文 Root 于 windowserver 进程。 LaunchDaemons 在不同的上下文中运行，因此它们无法直接与登录 session 通信。一些背景阅读:
- Starting/stopping a launchd agent for all users with GUI sessions
- How can you start a LaunchAgent for the first time without rebooting, when your code runs as a LaunchDaemon?
- launch agent from daemon in user context
我不知道如何在不使用 launchctl bsexec 的情况下让进程进入正确的上下文。 Launchd 从技术上讲有一个 API(launchctl 使用它)，但它没有很好的文档记录。您可以拉source来自 opensource.apple.com。
即使您继续使用 NSDistributedObject，如果可以的话，我也会尝试使用除引导服务之外的其他东西。正如我提到的，我倾向于使用其他工具并避免使用 NSDistributedObject。在我看来，出于同样的原因，REST 优于 SOAP，简单协议(protocol)通常也优于远程对象。 (YMMV)
关于macos - Mac 操作系统中的通信问题，我们在Stack Overflow上找到一个类似的问题： https://stackoverflow.com/questions/9230412/