Hi James,

I was looking through my QRecall log today, for the first time in quite a while, and I noticed the following error message occurring once or sometimes twice a day:

Unable to connect with helper
cannot establish a connection with helper
Port: QRecallHelper.28be5bb1

The hex number in the third line is different every time. The time of day when the message occurs varies, but it's always at odd times not associated with anything on QRecall's schedule. It's been going on for months, but apparently it's not serious, as the next scheduled task always occurs on time and completes without error. Any idea what's happening here?

-- Bruce

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.