Bruce Giles wrote:Any idea what's happening here?
When QRecall starts an archive action (capture, merge, verify, and so on) it launches a separate process that will perform that action. It then establishes a connection between itself and the new process in order to communicate the details of the action and any future cancel or pause messages. This communication is accomplished through a Mach kernel port.
When I first wrote QRecall, this worked flawlessly. Mach ports are, however, a limited resource; like file descriptors, there are only so many mach ports that can be used at any one time. As OS X has grown and the number of CPU cores, background threads, and processes continues to grow, it’s not that hard to run out of mach ports these days. When this happens, the process that's starting the action can’t open a commutations port with the process that's going to perform that action and … well … nothing happens, except for the log entry you’re seeing. The action process never gets its instructions, and eventually terminates without doing anything.
Mach ports can be registered under a name (via the mach port name server). Each port name must be unique, so the last eight characters of the QRecall port name is chosen at random. When the action process starts it picks a port name, registers it with the server, and then tells the starting process what that name is. The starting process then opens the named port and establishes its premanent communications link with the process.
I’m currently rewriting the inter-process communications logic that QRecall uses. I’m hoping to relay more on BSD pipes and less on Mach ports. I’m hoping this will make the communications between QRecall processes more predictable and robust.