[xmonad] bringing xmonad into the threaded world

[wagnerdm at seas.upenn.edu]

Quoting Mike Meyer <mwm at mired.org>:

> On Mon, 07 May 2012 02:06:31 -0400
> wagnerdm at seas.upenn.edu wrote:
>
>> 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.
>
> 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.

Perhaps silly is the wrong word. But:

Because it means any time I want to do something with X, but keep  
xmonad's response time snappy, I have to create a process, make sure  
that process is in xmonad's PATH with all the confusing debugging  
associated with that (some people on #xmonad actually didn't have  
xmonad in their $PATH!), figure out how to do IPC...

>> 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?

There's a hit, but considering xmonad's current strategy of completely  
syncing its internal state with X all the time, this is the wrong  
place to fix a performance problem.

> 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.]

I'm fairly certain that GHC will not context-switch during an FFI  
call. So using green threads may be OK. But I'm also not enough of an  
expert to say, and this way is certainly OK.

~d