Now, I've noticed that if I set the ASL_OPT_STDERR flag, I really cannot seem to get my printouts to have proper linebreaks in my shell (nor in Xcode's terminal). I recognize that this is the same problem as you reported in rdar://problem/5695926. Take this as an example: "This is\n a linebreak \n and here comes one more\n". That string will be printed exactly as is, that is \n isn't treated like a line break. However, Console.app seems to be displaying the string just as I intended it to be seen, with \n converted to a newline.

Again; thanks for some really good posts.

I think in your summary, the asl_log call is missing a parameter for level:

asl_log(client, /*msg*/ NULL, "printf-style format; interpolates values, such as %i", 42);

should be (?):

asl_log(client, /*msg*/ NULL, ASL_LEVEL_XXX, "printf-style format; interpolates values, such as %i", 42);

Early in your application startup, create a key for the per-thread ASL connection using pthread_key_create(). Pass in a destructor routine that closes the connection. That way, each thread's connection will be automatically closed when that thread exits. Store the key in a global variable.

When you need to log, call pthread_getspecific() to obtain the thread's ASL connection. If it comes back NULL, then this is the first time you're logging for that particular thread. In that case, create the connection for the thread and store it using pthread_setspecific(). The business of getting the connection and creating it if necessary should be hidden within a function, naturally.

If you prefer, in Cocoa you can use -[NSThread threadDictionary] to store the connection. In that case, you'd define your own class for holding an ASL connection, whose dealloc would close the connection. This seems to add complexity for no apparent benefit, though.

If you have multiple objects that each use one (and only one) thread, you can just put the connection in their class as an ivar.

If you have one object which messages from multiple sources pass through, I would suggest using performSelectorOnMainThread: to fob all the logging off on the main thread. This is a bottleneck, but you'd need a lot of messages to come in at the same time to cause a performance problem.

I should probably add this to the client connections post.

Question: what's your view on how to deal most effectively with logging from multiple threads in an app?