Wandering Thoughts archives

Solaris's impressive ABI compatibility

There are some things that Solaris is very good at; one of them is user-level ABI compatibility (at least for basic programs). As an illustration of just how good it is, I only recently noticed that on our Solaris 8 machines I am still routinely using some dynamically linked programs compiled in August of 1993 (which is probably when this group started using Solaris machines).

I hadn't noticed before now because the programs hadn't really changed since then (so I had no need to upgrade them), and because the compiled versions just kept on working so I didn't have to pay attention to them.

(Until recently, my Solaris version of rc was a statically linked binary from March 1994. I can't claim this as an unqualified success, because I was goaded into replacing it with a current version by an obscure glitch in some circumstances. But it's pretty striking that I didn't have any problems in normal use.)

My Solaris binaries that use X have fared less well, although this may be because X environments themselves have changed significantly since 1994. (For example, back then programs could get away with not dealing with TrueColor displays, especially 24-bit and 32-bit ones.)

(The program itself starts up, but fails with a BadMatch 'invalid parameter attributes' error on an X_PolyFillRectangle call. I wonder if I can dig up an 8-bit PseudoColor display somewhere around here to test it against; unfortunately Xnest can only force a PseudoColor visual as the default visual if the underlying X server has one to start with, and modern X servers and hardware don't seem to.)

Link: Threads Cannot be Implemented as a Library

I've already linked to this in passing, but I'm going to rerun it as an explicit link. Threads Cannot be Implemented as a Library by Hans Boehm makes the argument in its title:

We provide specific arguments that a pure library approach, in which the compiler is designed independently of threading issues, cannot guarantee correctness of the resulting code.

There is also a discussion of this paper at Lambda the Ultimate that may be interesting reading. On a quick skim of the LtU discussion thread, this Usenet article jumps out as a useful summary of the entire volatile and multiprocessor programming issue, ending up with the conclusion that using volatile is both unnecessary and harmful in shared-state concurrent programming.