Cocoa 分布式对象、长轮询、启动和“无响应” 在活动监视器中
场景：
我在 Mac 应用程序和 launchd 守护进程（用基础类编写）之间有一个基于分布式对象的 IPC。 由于我之前遇到过关于异步消息传递的问题（例如，我在服务器的根对象上有一个 registerClient: ，并且每当有事件发生时，服务器的根对象就会通知/调用客户端代理对象中的方法），因此我进行了长轮询，这意味着客户端“收获”来自守护进程的事件/通知列表。 这种“收获”是通过服务器对象方法调用完成的，然后返回一个 NSArray 实例。
它工作得很好，直到几秒钟，服务器对象的进程（通过 launchd 启动）开始被标记为红色，旁边带有“（未响应）”标签（在活动监视器内）。 就像我说的，从功能上讲，它运行良好，但我们只是想摆脱这个“不响应”标签。
如何防止出现“未响应”标签？
仅供参考，我之前已经做过基于 launchd 的流程，这是我第一次进行长轮询。 另外，我尝试了基于 NSSocketPortNameServer 的连接以及基于 NSSocketPort 的连接。 他们没有这个问题。 锁定也不是一个问题，因为使用的锁只是 NSCondition 的，我们记录并调试了程序，似乎唯一的锁定“问题”是在收获部分，实际上，它在功能上是有效的。 此外，客户端进程是用 PyObjC 编写的，而服务器进程是使用 ObjC 编写的。
提前致谢。
Scenario:
I have a Distributed-objects-based IPC between a mac application and a launchd daemon (written with Foundation classes). Since I had issues before regarding asynchronous messaging (e.g. I have a registerClient: on the server's root object and whenever there's an event the server's root object notifies / calls a method in the client's proxy object), I did long-polling which meant that the client "harvests" lists of events / notifications from the daemon. This "harvest" is done through a server object method call, which then returns an NSArray instance.
It works pretty well, until for a few seconds, the server object's process (launched thru launchd) starts being labeled red with the "(Not responding)" tag beside it (inside Activity Monitor). Like I said, functionally, it works well, but we just want to get rid of this "Not responding" label.
How can I prevent this "Not responding" tag?
FYI, I already did launchd-based processes before and this is the first time I did long-polling. Also, I tried NSSocketPortNameServer-based connections and also NSSocketPort-based ones. They didn't have this problem. Locking wasn't also an issue 'coz the locks used were only NSCondition's and we logged and debugged the program and it seems like the only locking "issue" is on the harvesting part, which actually, functionally works. Also, client-process is written in PyObjC while server process was written using ObjC.
Thanks in advance.
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（3）
示例该过程以了解其内容做或等待。
Sample the process to find out what it's doing or waiting on.
彼得的方法是正确的，尽管您可以通过简单的检查来弄清楚。 “没有响应”意味着您至少有 5 秒（以前是 2 秒，但他们在 10.4 中提高了）没有处理事件队列中的事件。 对于 UI 进程，这将创建一个旋转的等待光标，但对于非 UI 进程，您不会轻易看到效果。
如果这是一个基于运行循环的程序，则意味着您可能正在使用阻塞（同步）操作执行某些操作，而该操作应该通过运行循环和回调（异步）来完成。 或者，您需要第二个线程来处理阻塞操作，以便主线程可以继续响应事件。
Peter's correct in the approach, though you may be able to figure it out through simple inspection. "Not responding" means that you're not processing events on your event queue for at least 5 seconds (used to be 2 seconds, but they upped it in 10.4). For a UI process, this would create a spinning wait cursor, but for a non-UI process, you're not seeing the effects as easily.
If this is a runloop-based program, it means you're probably doing something with a blocking (synchronous) operation that should be done with the run loop and a callback (async). Alternately, you need a second thread to process your blocking operations so your mainthread can continue to respond to events.
我的问题实际上是使用签名 FNDR 获取进程 PID 的调用...该部分导致了“未响应”错误，并且它从来不是锁或长轮询部分。 对这些人感到抱歉。 但感谢上帝我已经找到了答案。
My problem was actually the call for getting a process's PID using the signature
FNDR... that part caused the "Not responding" error and it never was the locks or the long-polling part. Sorry about this guys. But thank God I already found the answer.