[xmonad] bringing xmonad into the threaded world

[wagnerdm at seas.upenn.edu]

Quoting Mike Meyer <mwm at mired.org>:

> 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