[xmonad] bringing xmonad into the threaded world

[Brandon Allbery]

On Mon, May 7, 2012 at 10:31 AM, <wagnerdm at seas.upenn.edu> wrote:

> Quoting Brandon Allbery <allbery.b at 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 at gmail.com
wandering unix systems administrator (available)     (412) 475-9364 vm/sms
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.haskell.org/pipermail/xmonad/attachments/20120507/a41fa071/attachment.htm>