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?