Both of the major MySQL bindings, HDBC-mysql and HDBC-odbc, use the libmysqlclient C library behind the scenes. With GHC's unthreaded runtime, which is still the default, an application using either will work fine. However, my middleware app is highly concurrent and uses software transactional memory (STM) to manage some shared state, and I have to use the threaded runtime. This is where my troubles began.

The symptom I observed was that I couldn't even connect to a database:

SqlError {
  seState = "", 
  seNativeError = 2003, 
  seErrorMsg = "Can't connect to MySQL server on 'xxxxx' (4)"}

After enough years of dealing with MySQL, you pick up some useful nuggets such as "the number in parentheses at the end of certain kinds of error message is a Unix errno value" (the library doesn't provide any other way to see what errno caused a failure, amusingly enough). The number 4 is EINTR, indicating that a system call was being interrupted.

I split my development time between a Mac and a Linux laptop, and today's hacking was on a Mac, so I fired up dtruss to see what was wrong:

dtruss -b128m myapp

(I'd much preferred to have been using Linux here. dtruss is vastly inferior to strace, and in fact in its default configuration, it doesn't work at all! That -b128m is necessary to give its kernel component enough of a scratchpad that it won't run out of space while sampling.)

The interrupted system call was connect, and sure enough, reading the library source code, we can see that the problem lies in the my_connect function:

  /*
    If they passed us a timeout of zero, we should behave
    exactly like the normal connect() call does.
  */

  if (timeout == 0)
    return connect(fd, (struct sockaddr*) name, namelen);

The comment is more or less accurate, but the library should be more careful in its use of the connect function: the caller of my_connect doesn't check for EINTR, and so the connection will fail if the thread receives a signal.

Why is the thread receiving a signal in the first place, though? GHC's threaded RTS sets up either a SIGALRM or SIGVTALRM signal to perform some internal book-keeping at a fairly high frequency, and it's the arrival of this signal that interrupts connect. Failure to check for EINTR and retry is a widespread problem in C code that uses system calls directly.

To work around this, I wrote a simple module that masks the RTS signals that the MySQL client library fails to handle, then performs an action. It ensures that it's running in a bound thread (GHC terminology for a lightweight thread that's tied to a heavyweight system thread) for the duration of the action.

{-# LANGUAGE EmptyDataDecls, ForeignFunctionInterface #-}

module RTSHack (withRTSSignalsBlocked) where

import Control.Concurrent (runInBoundThread)
import Control.Exception (finally)
import Foreign.C.Types (CInt)
import Foreign.Marshal.Alloc (alloca)
import Foreign.Ptr (Ptr, nullPtr)
import Foreign.Storable (Storable(..))

#include <signal.h>

withRTSSignalsBlocked :: IO a -> IO a
withRTSSignalsBlocked act = runInBoundThread . alloca $ \set -> do
  sigemptyset set
  sigaddset set (#const SIGALRM)
  sigaddset set (#const SIGVTALRM)
  pthread_sigmask (#const SIG_BLOCK) set nullPtr
  act `finally` pthread_sigmask (#const SIG_UNBLOCK) set nullPtr

data SigSet

instance Storable SigSet where
    sizeOf    _ = #{size sigset_t}
    alignment _ = alignment (undefined :: Ptr CInt)

foreign import ccall unsafe "signal.h sigaddset" sigaddset
    :: Ptr SigSet -> CInt -> IO ()

foreign import ccall unsafe "signal.h sigemptyset" sigemptyset
    :: Ptr SigSet -> IO ()

foreign import ccall unsafe "signal.h pthread_sigmask" pthread_sigmask
    :: CInt -> Ptr SigSet -> Ptr SigSet -> IO ()

With any luck, if we can get things complete, this will spur the Debian (and by extension, Ubuntu) Haskell team into finishing off their support for the Platform, in the spirit of friendly competition. That would leave us in the delicious situation of being able to tell curious people that almost any major Linux distro will make a good basis for developing and deploying Haskell applications. Sweet!

I have a fairly large C++ application handy, so I tried linking it on my dual core Thinkpad with 2GB of memory, running Fedora 8.

When I compile this application with debugging symbols enabled, it’s not exactly fast to link: it takes about a minute. Because the amount of data the linker has to chew through is impressively large, the actual time varies by up to 20% from one run to the next: all of those object files don’t fit into memory at once. This also has the unpleasant effect of paging out parts of apps I’m trying to use, such as Emacs and Firefox. Hmph.

In this situation, gold does indeed improve linking performance, bringing the linking time down to about 40 seconds. The poor laptop’s disk still spends a lot of this time grinding away due to the sheer volume of data, so once again the number isn’t very repeatable.

To eliminate the effect of memory pressure, I used “strip -g” to drop the debug information from the main app’s object files. (The libraries it links against still contain debug info, but they’re much smaller than the app itself.)

Stripping the object files speeds up the regular binutils linker by a factor of four, reducing linking time to 14 seconds. The laptop’s disk is no longer being touched. I can still edit text files after a link without big initial stutters. Whew!

When I switched to using gold as the linker, I was at first a little surprised to find that it actually works at all. This isn’t especially common for a complicated program that’s just been committed to a source tree. Better yet, it’s as fast as Ian claims: my app now links in 2.6 seconds, almost 5.4 times faster than with the old binutils linker!

When I ran “ld –help”, I noticed the tantalising options “–threads” and “–thread-count”, so I tried those. It turns out that thread support is not enabled by default: I reconfigured, rebuilt, and tried again. Running with “–thread-count 2″, the linking time drops slightly, to 2.3 seconds: that’s nearly 6.1 times faster than before.

Does the application actually work when linked by gold? Yes, so far with no signs of problems. It’s about 3% larger than the version produced by the old linker. I haven’t looked into why this might be.

Is gold ready for prime time? It’s not too far off. It doesn’t support the –build-id flag, which my copy of gcc 4.3 is convinced it wants (perhaps because I’m running Fedora). It doesn’t link the Linux kernel properly, because the kernel tortures the linker in twisted and innovative ways. Also, I have run into a few non-reproducible crashes when running in threaded mode, such as the following:

internal error in find_runnable_or_wait, at ../../gold/workqueue.cc:262

Overall, though, I’m very impressed, and I’m looking forward to the point where gold entirely supplants the existing binutils linker. I expect that won’t take too long, once Mozilla and KDE developers find out about the performance boost. Great work, Ian!

If you’re feeling impatient, you can download the final RPMs from the koji build page. I’ve got a build of Gtk2Hs pending, too, so I’ll be releasing that at the same time as the bump of GHC itself.

I’ve been using Fedora since 0.92 (Taroon), and while I’ve generally been happy with it, F7 is not exactly a model of stability or sleekness. Here’s a list of problems I’ve run into. My biggest problems so far have been with suspend and resume, and network drivers.

Suspend to RAM doesn’t work by default; when I resume, the screen is blank, and can’t be coaxed back to life save through a reboot. This is bug 243759. I came up with a fix (for my hardware, at least) in bug 237849. Richard Hughes’s fabulous HAL quirk site was the key to figuring out that one; thanks, Richard!

Suspend to disk (aka “hibernate”) works, some of the time. But it interacts poorly with the crummy quality of the current e1000 ethernet driver.

The e1000 driver is flaky in F7. If I boot with a live ethernet cable plugged in, it works. But if I plug one in after booting, it fails to detect the carrier signal, and simply never notices the cable. Bug 236956.

There is a workaround, of sorts. If I manually rmmod, then modprobe the driver again, it will detect the carrier signal. Unfortunately, after I do this, the next time that I try to suspend to disk, all of my network-related processes get stuck in an unkillable state, and suspend throws in the towel. Bug 245107.

If I try to use the screen backlight brightness control buttons, the screen goes black instead. Bug 220466.

If I disable the internal modem in the BIOS, sound no longer works. Bug 205603.

The new iwl3945 wireless driver simply falls over after a while, depending on the network configuration it’s talking to. Bug 240826.

By the way, I’m not claiming that these problems are in any way the fault of Dave Jones, Chuck Ebbert, the HAL guys, or other Fedora maintainers. They have a thankless job trying to clean up the endless flood of new bugs in upstream kernels, not to mention cascades of junk hardware and buggy BIOSes from vendors. I’m frankly relieved every time the kernel boots reliably at all.

On top of these stability and reliability problems, performance has taken a bit of a beating. F7 seems to take quite a bit longer than earlier releases to boot, something Dave Jones has quantified. The post-boot bloat also rises: there are more kernel threads and userspace daemons running than ever before.

On the positive side, 3D graphics works quite well. I can actually run OpenGL apps like Google Earth and Second Life without crashes, and get decent frame rates out of them. And of course I can turn on wobbly windows and induce vertigo and nausea within minutes, where previously I had to resort to using Windows to get that sensation.

The upgrade to 6.6.1 necessitated a bump of the release number of the Fedora Gtk2Hs package, too. There are no changes in the new release; it’s just built against the newer compiler release.

My Linux distribution of choice has long been Fedora. Unfortunately, unlike other modern Linux distros, Fedora doesn’t provide a simple graphical means to shrink an NTFS partition in its installer.

Since the X60 doesn’t have an optical drive, and I don’t have any USB storage like a memory stick or CD-ROM drive, I couldn’t easily boot into something like Knoppix. If I’d had such gear available, I could easily have shrunk the Windows partition using qtparted. So here are my notes on how to get dual-booting working, by hand, in a bare-bones environment.

Really, if there’s some way you can use a sane all-in-one GUI tool like qtparted to do all of this messy work, you should. You should think of these as the instructions of last resort for the terminally optimistic.

Since I had no suitable media handy, I installed Fedora onto the X60 over the network using PXE. (Getting a PXE server configured sounds scary, but I had one up and serving in less than five minutes on my older laptop. Granted, I’ve done this many times.)

When the Fedora installer (Anaconda) is running, it runs you through a series of questions in text mode, and then starts up an X-based GUI. Don’t run through any of the GUI setup steps yet. Behind the scenes, Anaconda also sets up some virtual terminals, one of which contains a root shell prompt. That root prompt is the key to shrinking your Windows partition.

To get to the virtual terminal with the root prompt, you’ll first need to press the key combination of Control+Alt+F1 to switch to the first virtual terminal. After that, you can press Alt+F2 to get to the second, Alt+F3 the third (I think this is the one where the root prompt lives), and so on. Alt+F6 will bring you back to the GUI.

Once you have a root prompt, you’ll need to find another system, such as the one you’re installing from, and download an ntfsprogs source tarball. Unpack it, and build static binaries. (You must have static binaries, because the install environment doesn’t provide shared libraries.)

tar zxf ntfsprogs-1.13.1.tar.gz
cd ntfsprogs-1.13.1
./configure --enable-really-static
make

(Don’t forget to make sure that you’re building binaries that can actually run on the machine you’re installing on! If you’re installing an x86_64 version of Fedora, for example, it doesn’t matter whether you build a 32-bit or 64-bit version of ntfsprogs. But the converse is not the case.)

Once the build has finished, find the ntfsresize program in the ntfsprogs subdirectory. This is what you’ll need to get onto the machine you’re installing on.

Go back to the root shell on the system you’re installing onto. Recent versions of Anaconda make ssh and scp commands available from the shell, so you can simply scp the ntfsresize program from the system where you built it into /tmp on the machine you’re installing on.

Before I continue, I must point out what should already be obvious: if you are foolhardy enough to follow any directions after this point, you could completely destroy all data on your disk. Proceed at your own risk! If you have any important data on the system, back it up.

You’ll need to use the fdisk command to find out the name of your Windows partition. If you have a newish machine, it probably contains a SATA drive, so you’ll probably need to invoke it thus:

fdisk /dev/sda

Just type p to print the partition table, and note the name of the big partition (there’s probably only one) that’s marked as HPFS/NTFS. Once you’ve done that, type q to quit out of fdisk.

Let’s assume that /dev/sda1 is your NTFS partition. The next thing to do is use ntfsresize to see what size it is:

/tmp/ntfsresize -i /dev/sda1

This will run for a few seconds, and spit out lots of information. The pertinent line to look for in the output begins with “You might resize at …”. Record that number: it’s the minimum you’re likely to get away with.

Now try a dry run of resizing. Let’s say you’ve chosen ten gigabytes as your target Windows partition size.

/tmp/ntfsresize -n -s 10G

Again, ntfsresize will run for a few seconds, and print lots of information. If it prints an error message, don’t try to follow any directions beyond this point. You’re on your own.

However, if the dry run completes successfully, you ought to be safe to resize the partition. This is the first point at which you can destroy things, so it’s not for the faint of heart. Simply run the same command as before, only without the -n option.

/tmp/ntfsresize -s 10G

This will take a few minutes to run. If it exits with an error message, this might be a good time to take up religion and prayer, or at least to look for your Windows install CD. That is, if your system shipped with one.

Assuming ntfsresize did its job, the next step is even more scary: you’ll have to fiddle with the disk’s partition table so that the NTFS partition’s size matches the size of the actual filesystem. Messing with the partition table is even more scary than resizing filesystems, so dust off that rabbit’s foot your well-meaning aunt gave you.

It’s time to run fdisk again, this time with prejudice.

fdisk /dev/sda

Once again, type p to print the partition table. This time, make a note of the start offset of the NTFS partition.

Next, you’ll need to delete that partition table entry, with d. It will ask you for the number of the partition to delete; if your NTFS partition is on /dev/sda1, you’ll be deleting partition 1.

With that partition table entry gone, you’ll be creating a new, smaller entry to replace it. To get started on this process, use n.

1. fdisk will ask you whether to create a primary or extended partition. Choose p for primary.
2. It will prompt you for the start offset of the partition. You must use the same start offset as the old partition had; this is likely to be the default.
3. When fdisk asks you for an end offset, give it a relative offset that’s the exact same size as you gave earlier to ntfsresize. For example, if you resized to ten gigabytes, type +10G as the end offset.

The new shrunken partition you created will not have an NTFS system ID. Use t from the main fdisk prompt to change its ID. The number to change it to is 7.

Once you’re done, use p to take a look at the new partition table. This won’t actually be written to disk yet. Once you’re sure it looks correct (has the same start offset as before, the correct smaller size, and the right system ID), use w to write out the new partition table and quit fdisk.

In case I haven’t been successful in stating the risks of using fdisk by hand, here are a few charming possibilities for you to consider.

• fdisk will make no attempt to ensure that your partition table is correct or consistent. Neither, most likely, will your operating system. It’s thus quite possible to accidentally cause your partitions to overlap. This can result in data corruption problems that might not surface until months later.
• If you hork your partition table badly enough, it can be a pain to subsequently install anything on the system at all. I’ve been forced once or twice to use dd to splatter zeroes all over a partition table in order to get it back to a state where I could do anything with the disk.
• Don’t say I didn’t warn you!

At this point, you can return to the Anaconda GUI installer by typing Alt+F6. Step through a few install screens. When Anaconda reaches the point of asking you about partitioning, you might be okay to let it partition automatically for you; I haven’t tried this, so I don’t know. I simply go with the custom disk layout option instead, and find to my satisfaction that I now have a big chunk of empty space to fill with swap and ext3 partitions. As you continue through the installation process, Anaconda should automatically set up the boot loader to let you boot into Windows or Linux.

One final thing to bear in mind: the next time you boot into Windows after your install is complete, Windows will probably run chkdsk during boot, to verify that its filesystem is still sane.

$ apt-cache search missingh libghc6-missingh-dev – Library of utility functions for Haskell, GHC6 package libhugs-missingh – Library of utility functions for Haskell, Hugs package missingh-doc – Documentation for Haskell utility library

$ ghc-pkg -l /usr/lib64/ghc-6.6/package.conf: Cabal-1.1.6, GLUT-2.0, HGL-3.1, HTTP-2006.7.7, HUnit-1.1, OpenAL-1.3, OpenGL-2.1, QuickCheck-1.0, X11-1.1, base-2.0, cgi-2006.9.6, fgl-5.2, (ghc-6.6), haskell-src-1.0, haskell98-1.0, html-1.0, mtl-1.0, network-2.0, parsec-2.0, readline-1.0, regex-base-0.71, regex-compat-0.71, regex-posix-0.71, rts-1.0, stm-2.0, template-haskell-2.0, time-1.0, unix-1.0, xhtml-2006.9.13

$ darcs get http://uebb.cs.tu-berlin.de/~magr/darcs/rdtsc/ $ cd rdtsc

$ runghc Setup.hs configure –user –prefix=$HOME Configuring rdtsc-1.1.2… configure: /usr/bin/ghc-pkg configure: Dependency base-any: using base-2.0 configure: Using install prefix: /usr/local …blah blah…

configure: No happy found configure: No alex found

$ runghc Setup.hs configure

$ runghc Setup.hs build Preprocessing library rdtsc-1.1.2… Building rdtsc-1.1.2… [1 of 1] Compiling System.CPUTime.Rdtsc ( System/CPUTime/Rdtsc.hs, dist/build/System/CPUTime/Rdtsc.o ) /usr/bin/ar: creating dist/build/libHSrdtsc-1.1.2.a

$ runghc Setup.hs install

$ ghc-pkg list /usr/lib64/ghc-6.6/package.conf: Cabal-1.1.6, GLUT-2.0, HGL-3.1, HTTP-2006.7.7, HUnit-1.1, OpenAL-1.3, OpenGL-2.1, QuickCheck-1.0, X11-1.1, base-2.0, cgi-2006.9.6, fgl-5.2, (ghc-6.6), haskell-src-1.0, haskell98-1.0, html-1.0, mtl-1.0, network-2.0, parsec-2.0, readline-1.0, regex-base-0.71, regex-compat-0.71, regex-posix-0.71, rts-1.0, stm-2.0, template-haskell-2.0, time-1.0, unix-1.0, xhtml-2006.9.13 /home/bos/.ghc/x86_64-linux-6.6/package.conf: rdtsc-1.1.2

$ ghci Prelude> :module +System.CPUTime.Rdtsc Prelude System.CPUTime.Rdtsc> rdtsc Loading package rdtsc-1.1.2 … linking … done. 3552638252

# pidof yum 30987

# strace -p 30987 Process 30987 attached – interrupt to quit futex(0xb7bf21a0, FUTEX_WAIT, 2, NULL <unfinished …>

# killall -9 yum

# rm -f /var/lib/rpm/__db.*

$ sudo yum install autoconf bzip2-devel db4-devel \

  expat-devel findutils gcc-c++ gdbm-devel glibc-devel gmp-devel \

  libGL-devel libX11-devel libtermcap-devel ncurses-devel \

  openssl-devel pkgconfig readline-devel sqlite-devel tar \

  tix-devel tk-devel zlib-devel 

lftp ftp://mirrors.kernel.org/fedora/core/development/source/SRPMS

mget python-2*.src.rpm 

mkdir -p /tmp/mypy/{BUILD,RPMS,SOURCES,SPECS}

rpm --define '_topdir /tmp' -ivh python-2*.src.rpm 

cd /tmp/mypy/SOURCES

sed -ie 's/DBLIBVER=4.5/DBLIBVER=4.3/' python-2.5-config.patch 

cd /tmp/mypy/SPECS

rpmbuild --define '_topdir /tmp/mypy' --define '__python_ver 25' -bb python.spec

sudo rpm -ivh /tmp/mypy/RPMS/*/*.rpm