fibre~thread

At last releasing SymbicLogKit. The kit is a simple logging/tracing framework polarized toward desktop (vs. server) development; an itch I’ve needed to scratch for quiet some time. I can already hear a poignant skeptic say that printf and NSLog do the job just fine, and that availability of other solutions such as Log4Coocoa and ASL (Apple System Logging) adds the insult to an injury.

I was not entirely happy with the existing solutions and the following points and decided to build my own framework.

• Tracing/logging/debugging code often serves a purpose long after its initial purpose, so it shouldn’t be removed much of the time following a debugging session. Instead logging code should be well thought out as to provide a developer with useful info in the future.
• If the above statement is accepted then we need a means of selectively blocking/enabling tracing code based on origin, level, thread, and other parameters. Without the ability to select what gets through we’ll simply get lost in the overly verbose output.
• Enabling/disabling parts of output should be snappy and should be done at runtime.
• A developer may want to do more useful things than printf with tracing output, so the output should be structured.
• The framework should be UI centric, nice to look at, and should be easy to include and take advantage of in desktop applications.

The core of the framework is a singleton class called SYLogger. The instance of this class allows a user to add objects conforming to SYLoggerChannel protocol. Such objects are essentially output channels for a logger instance. There are two such objects provided by the framework: SYConsoleView and NSLoggingChannel.

SYConsoleView is an NSView that can be embedded into your application much the same way as any NSView subclass. The view is a tabular console for your output. On the other hand NSLoggingChannel is a simplistic channel that forwards your output to NSLog(...) call having formatted it nicely.

In order to make use of the framework the channels must be added to SYLogger instance. Messages are sent to the logger by invoking one of the following macros. There are 4 debugging levels defined at the moment (Debug, Info, Warning, Error) each assigning an immediacy level to a message. The variadic macros take NSString*s as parameters, the first being a format string (think [NSString stringWithFormat:...]).

There’s also an SYConfiguratorView which enables a user (a developer typically) to configure the logger. By configure I mean to provide a list of class-selector-level tripples describing which output should be blocked. The control is nothing more than a table with the first column hosting an ICU regular expression for class-name, the second hosting an ICU regular expression for selector-name (e.g. “dictionaryWithObjects:forKeys:count:”, “array”, etc.).

The above screenshot, for example, represents a configuration that blocks output from within drawRect: selectors of all classes whose names end in “View” as well as from all selectors whose name begins in “run” irrespective of a class they belong to.

I often come across multithreaded codes that work 99.9% of the time but share a common flaw. They exhibit unrepeatable behavior on occasion because such codes treat assignment as an atomic operation.

This assumption is fundamentally flawed since assignment such as  int64_t a=b; may take 2 or ore CPU instructions to complete. For instance, in the case of a 64-bit integer assignment could execute inside two instructions; one for low- and high-word of the register. The instruction bipole could in theory (and does in practice) get interrupted by other threads. Such bugs are extremely difficult to track and isolate since assignment is indeed atomic for most cardinal datatypes in C/C++ but isn’t required to be. To appreciate the complexity multithreading gives rise to especially when multiple cores/CPUs are involved read this article.

Many of my fellow developers could save themselves from glib frustrations of caffeine charged moonwalks through late-night debugging sessions by being more conscious of non-atomicity of assignment. In fact, an added benefit is that an understanding these facilities often eliminates the need for synchronization primitives in a number of situations consequently making codes faster and easier to follow.

The facilities are a part of Kernel framework and can be conveniently imported in ObjC as follows:

#import <libkern/OSAtomic.h>

I should point out that atomicity of (at least assignment) could also be achieved through the use of ObjC 2.0 properties which are atomic by default. However, the sweet of OSAtomic-operations is reacher and eliminates the need for overzealous property syntax.

There are however a few quirks requiring our attention if we are to make use of the API. OSAtomicXXX calls require their arguments to be aligned at natural boundaries in memory. Specifically, 32-bit variables must be aligned at 4 byte boundaries and 64-bit ones at 8 byte boundaries. The easiest way to insure that such alignment takes place in g++ compiled code is to use a proprietary extension. Also don’t forget to declare them volatile since a compiler may not warn you if you omit volatile from declaration. The following code demonstrates how one may declare instance variables for use in OSAtomicXXX calls.

NSValueTransformers can be extremely useful, especially when one wishes to make heavy use of bindings in Interface Builder. This facility is typically used to modify values displayed by a control in a declarative way. The following example illustrates a simple NSValueTransformer subclass that does nothing more than chops away a file extension from a string.

In order to make use of the subclass in IB it needs to be registered by name with the system as is done in the above code example. Once registered a transformer can be used inside, say, a table column as shown below.

Apple docs lack clarity when it comes to whether IBOutlets retain objects they point to. However a new way to specify outlets in Obj-C 2.0 saves the day.

This mechanism allows a developer to control retention behavior association with an outlet. Why should you care? The story with loading a nib (xib) file is that top-level objects are returned retained and it is left up to a developer to release them when they are no longer needed. Misunderstanding of this detail results in numerous leaks across applications.

A way to avoid tracking the top-level objects is to structure nibs so that every top-level object is reachable from the “File’s Owner” and to release top-level objects upon loading. However, this strategy brings about sad results unless one ensures that IBOutlets are always retained.