Quoting Don Stewart
xmonad isn't threaded because the X server doesn't allow concurrent access -- it will crash.
This is only partly accurate, as I've learned over the last few days: one Display per thread is a (the) safe way to do concurrent server access. Even if it *were* only possible to access X from exactly one thread, it's not clear to me that this would definitely mean that xmonad itself couldn't be multithreaded. Only that messages intended for the X server would all have to go through one centrally coordinated thread. I'd love to see the architecture of xmonad shift so that there are separate threads listening for X events and sending X commands (using two different Displays), but it's not clear to me what the right API for user code is. Perhaps the current model -- where it's your responsibility to open a display whenever you want to fork, and there's no central coordination -- is the best we can hope for. It's also a much more significant change than the small one I had wrongly hoped would be sufficient. ~d