Algorithm toolbox

I have released a preliminary version of an algorithm toolbox. The toolbox includes van Emde-Boas trees, intrusive AVL trees (thus, applicable in scenarios where there are no memory management facilities), and exhaustive permutation tester. The code is written in C++ and may be obtained here.


Solaris 11, xemacs and dbx

I have recently installed Solaris Express (Solaris 11), first in one virtual machine and then on "bare metal". I have to say that I'm very pleasantly surprised. The installation went very smooth, the only "configuration" neccessary was to enter time, location, select additional locales, type in the root password and to create a new non-root user upon first login. The default desktop is GNOME and looks very polished up. Security-wise, the installation seems very sane. There are many services bound on TCP ports, but almost all of them only to the loopback interface (meaning that only local programs can connect to them). The only publicly open ports are 111 (rpcbind) and 22 (ssh), 6011 and 6010 (I guess, X). And sshd is configured to not permit root logins by default.

I tried Sun Studio 11, but.. being used to emacs, it doesn't feel quite right (+ it's not comfortable to use it if you're running it over remote X11 connection). However, Solaris has a very nice toolbox for programmers: dbx, mdb, dtrace and tnf (man tracing), different malloc libraries, etc. It's really very advanced OS, and very developer-friendly. Plus there are zones, fine-grained privilege and role system which works... And everything is excellently documented in man pages. I'm too short on time right now to describe all the goodies, but.. I'm impressed. By the installation, default settings, and overall consistency and look&feel of the system. I can only say excellent work to all the Solaris developers, and a big thanks to Sun for making it all available at no charge.

Now, to the topic: I had a problem with xemacs not displaying source files when I used it with dbx to debug a multi-directory project. The problem turned out to be that dbx does not by default display full path to the source file. xemacs looks for the file in the wrong directory and consequently does not show the source you're supposed to be debugging. You can solve this problem by putting the following line in your .dbxrc:



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 */
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.