Spam, viruses and addressbooks

How do you know that someone has added your otherwise unpublished email address to their addressbook(s)? Of course, you suddenly start getting spam! I strongly suspect that there exist viruses/trojans whose only task is to steal data from your addressbook and send it away to .. (someone).

Linus on volatile

I'm referring to this thread on kerneltrap.org, where Linus is cited to be saying:
- in other words, the *only* possible meaning for "volatile" is a purely
single-CPU meaning. And if you only have a single CPU involved in the
process, the "volatile" is by definition pointless (because even
without a volatile, the compiler is required to make the C code appear
consistent as far as a single CPU is concerned).

He's absolutely wrong in his statement here (namely, that volatile is "by definition" pointless for a single CPU). The C99 standard says that any access to volatile object is a side-effect. This does not mean that compiler optimizations are effectively disabled; rather it means that the compiler must generate memory access instruction instead of caching the value in the register. [This is because accesses to volatile objects may produce side-effects, so the read value may change between reads without an intervening store instruction.]

Now, consider the following simple code in a uniprocessor configuration:

while(!flag) ;

which simply waits for the flag to become true (e.g. set by an interrupt handler). If flag is not declared as volatile, the compiler might well generate an infinite loop, but if the flag is declared as volatile, the compiler must generate code that will check the physical memory location in every iteration and thus the flag change from an interrupt handler will be detected.

So, volatile is important even on uniprocessors whenever there is a possibility of executing asynchronous code (e.g. interrupts). And its semantics is defined well enough to prevent errors like the one I have described above.

Oh well, I don't really care nor shall I bother to comment on this on the kernel mailing list. It's his kernel, I use it only on my desktop and I don't really care what future impact this change will have (and it might have far-reaching consequences that are really hard to discover; as any bugs related to asynchronicity). I have said long time ago that I'd never consider Linux for "serious" applications (i.e. anything else than a cheap desktop), and such displays of blatant ignorance by its leading developer just make my stand firmer.

More python brokenness: distutils

So I tried to compile Mercurial on Solaris with Sun's native compiler. I set CC and CFLAGS environment variables, but, as documented in distutils manual, the CFLAGS set in the environment are added to some predefined set of flags. This set of flags was adjusted to gcc, and Sun's compiler broke (no wonder) on some of gcc's options. It seems that compiler options are hardcoded in distutils at some obscure place. "Great" work!

After ca. 30 mins of fiddling around and searching on google, I recompiled the module using gcc.

Concurrent shared memory allocator

I have recently adapted Solaris's libmtmalloc(3) to satisfy allocation requests from shared memory segments; it works both with POSIX and SYSV shared memory. You can get the code here. I knew about a similar project, but I have no idea how well does it scale with increasing number of concurrent processes.

Prex, DTrace and linux lameness

Adam Leventhal has in his blog exposed the lameness of the SystemTap team (e.g. they claim that they weren't inspired by DTrace at all, but output format of some of their utilities is identical to that of DTrace). He also took an amusing photo showing that users are not very happy with SystemTap.

But I want to point to another very useful tool that got completely shadowed by DTrace: TNF tracing. In short, it is "printf() debugging" on steroids; read the tracing(3TNF) man page for more details. The TNF logging probes must be manually inserted in the source code at places where printf() would be put, and they produce no output by default. When you run the program under the control of prex(1) program, you may choose to log the otuput of all probes, or select just a subset of them (they are named!). The trace is later analyzed with the tnfdump(1) program. The best thing is that prex works also on running programs; it can attach to them, collect data and detach at later point.

TNF has been an enormous help in finding and correcting complex, time-dependent problems that I'd have much harder time to resolve otherwise.

Solaris signal handling bug, part 2

My initial report has been confirmed to be a genuine bug. Even more interesting, the bug has been introduced in Solaris 8, and hasn't been noticed until few days ago. Wow :)