On Mon, May 7, 2012 at 10:31 AM, <wagnerdm@seas.upenn.edu> wrote:
Quoting Brandon Allbery <allbery.b@gmail.com>:
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).

These two caveats sound like a great argument for applying this patch bundle to me.

Then you don't understand the reason for them, and need to reconsider what you think threading is going to accomplish here.

Synchronous is exactly what it sounds like; the code was "threaded" but not in a useful way, and using an OS thread instead of a green thread would not have fixed its problem.  (The main thread was in fact blocked on the child thread, waiting for it to produce a result.  The rewrite I've been working on makes this asynchronous... and in fact no longer requires any threads at all; the threading it was doing wasn't necessary or even sensible.  It was just broken code, possibly written by someone who thought that threads are magic sauce that fixes any situation where you need two chunks of code in the same program to process data at the same time.  (The thread magic sauce just turned their logic error into a deadlock.)

--
brandon s allbery                                      allbery.b@gmail.com
wandering unix systems administrator (available)     (412) 475-9364 vm/sms