On Mon, May 7, 2012 at 5:29 AM, Mike Meyer
There have been various times when I've wished I could just spawn a thread in xmonad. Just recently, for example, it was pointed out to me that the default mod+q binding starts a brand new process just to keep xmonad responsive while it recompiles the configuration file. This is silly.
I'm not convinced that is either a problem or "silly", but it can be changed without changing X11 to threaded because it doesn't actually use X11 in a dangerous way within a thread. Also be aware that a number of contrib modules *already* use threads... green threads, which open their own $DISPLAY connections. This is entirely safe as long as you don't do something that would block in an FFI call or that would expect the xmonad main loop to run while simultaneously expecting a *synchronous* response (as the infamous putSelection did). Why is it silly? It's not like the overhead of starting a new process
is going to be anything but noise compared to recompiling the configuration file.
Indeed. ghc and its invocation of ld are going to be the visibly expensive part.
Here is a patch bundle that makes xmonad ask X to be thread-safe, and rewrites the default mod+q binding to take advantage of the new thread safety.
What's the performance hit from making X thread-safe?
Significant. It's worth remembering that one of the more significant open bugs has to do with spending too much time context switching with the X server when sweeping the mouse across multiple windows... this will get a *lot* worse if Xlib is constantly grabbing and releasing a mutex on every single call (which is how it does thread safety; it's not even remotely smart about it). For that matter, if you are using Haskell threads instead of OS
threads, do you need to make X thread safe? [Sorry if this is a silly question - I'm not really familiar with using Haskell threads.]
Green threads are fine, aside from you can't safely use the main connection to the Display because you can't push back arbitrary numbers of arbitrary events that you don't care about, and if you silently drop them because you don't care about them then the main loop isn't seeing stuff it needs to see. As mentioned above, the usual workaround is to open your own connection. Building xmonad with -threaded gets you OS threads, with all their potential problems. -- brandon s allbery allbery.b@gmail.com wandering unix systems administrator (available) (412) 475-9364 vm/sms