Asynchronous interapplication communication on Mac OS X

Question

On Mac OS X, I have a process which produces JSON objects, and another intermittent process which should consume them. The producer and consumer processes are independent of each other. Objects will be produced no more often than every 5 seconds, and will typically be several hundred bytes, but may range up into megabytes sometimes. The objects should be communicated first-in-first-out. The consumer may or may not be running when the producer is producing, and may or may not read objects immediately.

My boneheaded solution is

• Create a directory.
• Producer writes each JSON object to a text file, names it with a serial number.
• When Consumer launches, it reads and then deletes files in serial-number order, and while it is running, uses FSEvents to watch this directory for new files arriving.

Is there any easier or better way to do this?

Answer 1

The modern way to do this, as of Lion, is to use XPC. Unfortunately, there's no good documentation of it; there's a broad overview in the Daemons and Services guide and a primitive HeaderDoc-generated reference, but the best way to get introduced to it is to watch the session about it from last year's WWDC sessions.

With XPC, you won't have to worry about keeping serial numbers serial, having to contend for a spinning disk, or whether there's enough disk space. Indeed, you don't even have to generate and parse JSON data at all, since XPC's communication mechanism is built around JSON-esque/plist-esque container and value objects.

Answer 2

Assuming you want the consumer to see the old files, this is the way it's been done since the beginning of time - loathsome though it may be.

There's lots of highish tech things that look cleaner - but honestly, they just tend to add complexity and/or deployment infrastructure that add hassle. What you suggest works, and it works well, and it's easy to write and maintain. You might need some kind of sentinel files to track what you are doing for crash recovery, but that's probably about it.

Hell, most people would just poll with a sleep 5. At least you are all all up in the fsevent.

Now if it was accepable to lose the events generated when the listener wasn't around; and perf was paramount - it could get more interesting. :)