<div dir="ltr">On Mon, May 7, 2012 at 5:29 AM, Mike Meyer <span dir="ltr">&lt;<a href="mailto:mwm@mired.org" target="_blank">mwm@mired.org</a>&gt;</span> wrote:<br><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div class="im">&gt; There have been various times when I&#39;ve wished I could just spawn a<br>
&gt; thread in xmonad. Just recently, for example, it was pointed out to me<br>
&gt;   that the default mod+q binding starts a brand new process just to<br>
&gt; keep  xmonad responsive while it recompiles the configuration file.<br>
&gt; This is  silly.<br></div></blockquote><div><br></div><div>I&#39;m not convinced that is either a problem or &quot;silly&quot;, but it can be changed without changing X11 to threaded because it doesn&#39;t actually use X11 in a dangerous way within a thread.</div>
<div><br></div><div>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&#39;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).</div>
<div><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div class="im">Why is it silly? It&#39;s not like the overhead of starting a new process</div>
is going to be anything but noise compared to recompiling the<br>
configuration file.<br></blockquote><div><br></div><div>Indeed.  ghc and its invocation of ld are going to be the visibly expensive part.</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">

<div class="im">&gt; Here is a patch bundle that makes xmonad ask X to be thread-safe, and<br>
&gt; rewrites the default mod+q binding to take advantage of the new thread<br>
&gt;   safety.<br>
<br>
</div>What&#39;s the performance hit from making X thread-safe?<br></blockquote><div><br></div><div>Significant.  It&#39;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&#39;s not even remotely smart about it).</div>
<div><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">For that matter, if you are using Haskell threads instead of OS<br>
threads, do you need to make X thread safe? [Sorry if this is a silly<br>
question - I&#39;m not really familiar with using Haskell threads.]<br></blockquote><div><br></div><div>Green threads are fine, aside from you can&#39;t safely use the main connection to the Display because you can&#39;t push back arbitrary numbers of arbitrary events that you don&#39;t care about, and if you silently drop them because you don&#39;t care about them then the main loop isn&#39;t seeing stuff it needs to see.  As mentioned above, the usual workaround is to open your own connection.</div>
<div><br></div><div>Building xmonad with -threaded gets you OS threads, with all their potential problems.</div><div><br></div></div>-- <br>brandon s allbery                                      <a href="mailto:allbery.b@gmail.com" target="_blank">allbery.b@gmail.com</a><br>
wandering unix systems administrator (available)     (412) 475-9364 vm/sms<br><br>
</div>