[xmonad] bringing xmonad into the threaded world

[wagnerdm at seas.upenn.edu]

Quoting Don Stewart <dons00 at gmail.com>:

> 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