Windows Vista and Visual Studio

I've bought a new laptop, got 64-bit Vista business with it, so I said - heck, let's give it a try. After one month of using Vista, I don't miss linux desktop at all. I have power management that works all of the time (and that locks the screen after wakeup, without any special configuration!), Flash that does not crash at least once a day (crash on linux manifested most often in the flash plugin eating 100% of CPU), sound system and mixing which works out of the box (no need for mysterious sound daemons that will enable multiple sound applications running simultaneously), plus availability of software for gadgets (garmin gps, nokia phone). I have even found a nice and free virtual desktop manager (VirtuaWin). One month after using Vista.. I won't be installing linux on the laptop anytime soon :-)

You have probably heard that User Access Control (UAC) is PITA, and there are a bunch of cookbooks on the net instructing on how to disable it. Coming from UNIX background, I find it rather natural that you have to type in admin password before performing system-critical tasks. Suggesting to people that they turn off UAC is rather irresponsible, and I have not done it. I like being warned when some operation requires elevated privileges. Oh, and I have turned off the sidebar - gadgets there are mostly useless and they just increase the startup time (which is, I must say, rather decent).

I have found replacement for all of the tools that I used under linux, except one -- development tools. And now, my comparison standard is not linux, but Solaris, with Sun's native developmet tools, CMake and dbx. (BTW, Solaris dbx just rocks! gdb is a poor match for it.) I have installed Visual Studio 8 Professional (I have free license through MSDNAA), and it has several shortcomings in comparison with Solaris tools.

First, I've heard many windows developers say that VS debugger is one of the best, but I find it rather mediocre compared to dbx. VS debugger does not recognize C++ overloaded iterators (so you can't persuade it to show you *it where it is some C++ iterator class) and it is a pain to display deeply nested data structure (just print -r in dbx). VS has even its own embedded command-line interface, but nothing indicates that these features are available through it. Sure, VS debugger is nice for single-stepping through the code, but this is not the way I usually debug the code. (What usually happens in my debugging session is that some assertion/check triggers a crash, I inspect the core dump, put a breakpoint near the offending place, and quickly print few variable values.) On the upside, the VS debugger understands STL containers and can display them in a nice form. But I'd go for dbx any day, only if it were available for Windows.

Oh yes, changing command-line arguments through IDE for debugged programs is PITA :-) If I run the program from the shell and it crashes, it takes several seconds to drop into the debugger, which is kinda annoying.

Another complaint is that VS does not seem to come with a decent profiler such as gprof on Solaris. Most people recommend to use Intel VTune, which costs money. Sun has recently released (free!) SPOT tool which produces a nice report of hot-spots over several runs of your program, in the form of cross-linked HTML pages and graphs.

Then there's DTrace which is currently unique to Solaris and some BSD variants (OS X, FreeBSD?).

Lastly, project configuration management is easier with CMake. I have not yet figured out how I can persuade VS to inherit project properties from the master "solution" properties. Given that projects have parent projects, I should probably play with a deeper project hierarchy. (But why can't I set master settings in the "solution"?! Bleh.)

IntelliSense is nice, but.. it doesn't work all of the time (I see rather often a message in the status bar that IntelliSense couldn't find a completion.. ). Though, when it does work, it sometimes saves me a lookup of member name.

In conclusion - Vista is a rather nice environment for everyday work and it is very stable. However, Microsoft's C and C++ development tools are no match to Solaris's tools, at least when it comes to lower-level stuff. (Maybe not so surprising, UNIX is traditionally C and C++ oriented environment, while MS is moving towards .NET). I'm definitely somewhat less efficient in development with VS (though not drastically); I don't know (yet) whether this is because I haven't learned all the features, or because Solaris tools simply are superior and have no match in functionality in VS.

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.

Linux signal handling is broken

Enter sigaction() in combination with SA_SIGINFO flag. Such signal handler accepts three arguments, the third being the context (full machine state needed to resume it, eg. registers) of the interrupted thread.

First problem: linux ABI is broken. The FP state in the uc_mcontext member of the ucontext_t structure is pointer, instead of value. This makes copying of the context nontrivial.

Second problem: You can't use setcontext() to leave signal handler and jump into another, previously saved, context. (Or, for that matter, you can't use it to return to the very same context passed as argument to the signal handler.) In other words, signal handler like

static void sighandler(
  int signo, siginfo_t *psi, void *pv)
{
  memcpy(puc_old, pv, sizeof(ucontext_t));
  /* choose another context to dispatch */
  setcontext(puc_another);
}

does not work. It does not restore signal mask specified in the puc_other, does not reestablish alternate signal stack, etc. However, this scheme works flawlessly on Solaris.

How am I fixing it on Linux? I walk the stack frames (following the saved stack frame pointer), modify the return address so that the signal handler returns to itself instead to the interrupted context, etc. Very ugly and nonportable.

Not to mention that I'm relying on luck: it seems that, under current linux kernel, it is not possible to atomically restore signal mask and return from signal handler to context other than the immediately interrupted one. (Heck, it's not even possible to do it nonatomically without resorting to "black magic" involving reading hex dumps of stack frames.)

I'm installing Solaris in a virtual machine to try it out, and I'm seriously considering to move my development to Solaris.

How to not debug programs

I was drawn to this article, titled "Signals as a Linux debugging tool", by a recent link on the OSNews site. The subtitle writes "Intelligent signal handling finds bugs faster". Two things are wrong about this article.

The first thing is that the author's code examples have printf function in a signal handler to output register values when a fault happens. This is undefined behaviour, as the printf function is not listed as async-signal-safe in the POSIX standard. Ironically, an article titled "Use reentrant functions for safer signal handling" is listed among the references.

The second thing is that the author suggests an unbelievably complicated way of finding bugs. Once your signal handler with undefined behaviour has dumped the values of registers to your terminal, you are supposed to use objdump to disassemble your program executable, find the faulting location, and somehow map it to your program source.

I wonder whether the author actually knows how to make a program dump core when it faults, what to do with the core file, and how to use a debugger, such as gdb. (Hint: debuggers are much more powerful and convenient to use than what the author suggests in the article.) It's surprising that such a misleading, low-quality article can show up on an IBM's web site.

NILFS for Linux

Today I've seen a reference to NILFS, a log-structured filesystem for Linux. It's interesting how they've put the most important "feature" at the bottom of the "Current status" page. Looking at the page, the first important thing one notices is that the work on garbage collector is ongoing. Doesn't sound well. At the bottom of the page, they conclude under known bugs with "The system hangs on a disk full condition." How nice :)

On a more serious note, I think that it's great that someone is working on alternative filesystems. NILFS can, for example, support "time travel".