[xmonad] bringing xmonad into the threaded world

wagnerdm at seas.upenn.edu wagnerdm at seas.upenn.edu
Mon May 7 16:28:32 CEST 2012

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.


More information about the xmonad mailing list