Quoting Mike Meyer
After a quick glance at the patch, it should mostly work if you use a real OS fork instead of a forkIO (because you're still doing IPC via the X server), and also have the nifty protected address space that comes with using a modern facility instead of threading.
My new understanding of the situation (which is very possibly still flawed!) is that the patch I proposed has too much thread safety in one axis and not enough in another. It's too much thread safety in the sense that it calls initThreads, and too little thread safety in that it uses the same connection to the display for both the main event loop and the thread that signals xmonad to restart once the recompilation is finished. The result is that the recompilation happens concurrently with the event loop, but as soon as it comes time to signal xmonad to restart, only one of the event loop thread or the signal thread runs. If it happens to be the event loop thread running, this means the signal to restart blocks until the next X event happens -- which may be far, far in the future if the user sits there doing nothing waiting for xmonad to restart. Dumb. The right thing to do (I think! I'm still no expert) is to open a new connection to the display in the spawned recompile-and-signal thread; then it's unnecessary to call initThreads. It should be easy to make a patch that does this kind of thing instead of spawning a new process, I just haven't done it. ...and I probably won't, either, because it's fixing the symptom, not the problem: currently, the only way for spawned threads to communicate with the main thread is through X! ~d