[Xmonad] xmobar-0.7rc1 testers needed

[Spencer Janssen]

On Tuesday 17 July 2007 13:43:23 Andrea Rossato wrote:
> On Tue, Jul 17, 2007 at 01:12:59PM -0500, Spencer Janssen wrote:
> > I tried replacing forkOS with forkIO, and things still seemed to work.
> > However, removing -threaded caused serious hangs before text updates
> > (perhaps only happening after each expose event?).
>
> without -threaded I would expect that *only* an expose event would
> update the window (with override_redirect this means switching to a
> console or another X server and back, or pressing F11 with firefox).
>
> The safe call will run an OS thread only with -threaded, right?

Right.

> In other words, with -threaded using forkIO or forkOS makes no
> difference if we make a safe call.
>
> But, as you noted before, we have XNextEvent on one thread, and
> XSendEvent on the delayed thread (the one that will send the event to
> the blocked one - to XNextEvent).

On my machine, XSendEvent and XNextEvent do not seem to block each other -- 
but I'm not sure whether this is the case for older versions of Xlib.

> For this reason I think it is appropriate to use forkOS together with
> -threaded.

We should try to avoid forkOS if at all possible -- forking an OS thread 
requires much more memory than a lightweight Haskell thread.

> It works perfectly here, but I have that strange case of that specific
> machine with a broken tool chain. It is a dual core (two processors
> are seen by the kernel) and all concurrent threads get blocked. The
> only way to update xmobar is to create an expose event.
>
> This is the only thing that puzzles me. And I don't have enough
> knowledge of all this FFI stuff (moreover mixed with concurrency -let
> alone the C side of the moon) to work it out. I'm afraid it is just
> too much for me.
>
> Thanks for you kind attention, though.
>
> Andrea
>
> BTW, I've been thinking about it, and I do not see any other possible
> solution for the specific problem of blocking a thread and resuming it
> in two different cases: an event *or* the elapsed time. You need the
> real event or another thread that sends a fake event. Am I right?

It is possible, but annoying.  It requires a magic version of nextEvent that 
doesn't block inside foreign calls.  Thankfully, this isn't so hard to write 
with threadWaitRead and XPending.  With this magic nextEvent, we can use 
asynchronous exceptions to interrupt the thread with a timer.  I've sent you 
a patch that implements this.

The next step, I think, is to remove the 'refresh' configuration entirely -- 
just have plugins throw exceptions to the event/drawing thread whenever they 
update.


Cheers,
Spencer Janssen

PS: xmobar is quite nice, I use it as my statusbar now.