[Xmonad] xmobar-0.7rc1 testers needed

[Andrea Rossato]

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?

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).

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

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?