On Nov 6, 2007 11:21 PM, Spencer Janssen wrote:

Sadly, SIGCHLD doesn't seem to be a good solution here. Certain parts of xmonad collect child processes with waitForProcess, which throws an exception if the process has already been collected.

Good point. One of those places is in Main.hs, which waits for the ghc process to recompile .xmonad/xmonad.hs. That doesn't seem very elegant, since the window manager is frozen until ghc finishes. Seems like that ought to be multithreaded, so the window manager can keep responding during the compile. There's still the previous version of this patch, that puts a getAnyProcessStatus in the main loop in Core.hs. It's not clear if that method has a performance impact. Another possible solution would be to have a child thread that does blocking getAnyProcessStatus forever.

On Wed, Nov 07, 2007 at 11:27:33AM -0800, Don Stewart wrote:

dbenbenn:

...

On Nov 6, 2007 11:21 PM, Spencer Janssen wrote:

...

Sadly, SIGCHLD doesn't seem to be a good solution here. Certain parts of xmonad collect child processes with waitForProcess, which throws an exception if the process has already been collected.

Good point. One of those places is in Main.hs, which waits for the ghc process to recompile .xmonad/xmonad.hs. That doesn't seem very elegant, since the window manager is frozen until ghc finishes. Seems like that ought to be multithreaded, so the window manager can keep responding during the compile.

Yes, I actually ran into that this morning. There was a 2 second delay I wasn't expecting as ghc swapped in. Maybe for we can avoid the call in the unchanged xmonad.hs case, by checking stamps ourselves, rather than asking ghc to do that.

Spencer, waddya think?

While we're at it, might we be able to be smarter than ghc, and look to see if the xmc or xmonad packages have changed since the last compile? Currently, we need to touch .xmonad/xmonad.hs on every recompile/restart, which seems foolishly unnecessary. -- David Roundy Department of Physics Oregon State University

On Fri, Nov 09, 2007 at 08:51:24AM -0500, Devin Mullins wrote:

On Wed, Nov 07, 2007 at 11:27:33AM -0800, Don Stewart wrote:

...

Yes, I actually ran into that this morning. There was a 2 second delay I wasn't expecting as ghc swapped in. Maybe for we can avoid the call in the unchanged xmonad.hs case, by checking stamps ourselves, rather than asking ghc to do that.

Couldn't we avoid the delay by making the `ghc --make` trigger on mod-q, rather than at initialization? I think the chances of somebody running xmonad for the first time with a modified config are small.

Or maybe run a full ghc --make on mod-q (rather than using our own time-stamp check), but use the time-stamp check on startup. It's a bit hacky, but gives us a better recompile check on mod-q (when you might have touched a sub-module), but quick startup time at startup. -- David Roundy Department of Physics Oregon State University