[xmonad] Slow reload

[Yitzchak Gale]

I wrote:
>> When xmonad needs to recompile xmonad.hs during
>> a reload, that can take time...
>> let's say I press mod-Q again during that time...
>> KDE gets the key press. If the current window happens to be a Konsole,
>> for example, that causes the mod key to stop working
>> even after the xmonad reload finishes.

Spencer Janssen wrote:
>  This shouldn't happen.  Please give detailed steps to reproduce.

OK. I'm running xmonad 0.7 (the Debian xmonad package
from unstable, installed on Debian testing) and KDE 3.5.
My xmonad.hs is the one on the wiki page:
http://haskell.org/haskellwiki/Xmonad/Using_xmonad_in_KDE

1. Make a change to xmonad.hs that will cause its recompilation
to take more than two seconds.
2. Make a Konsole window the current window.
3. Press mod-Q.
4. Wait about one second.  Then, before the red border flashes,
4. Press mod-Q again.

Now none of the xmonad mod-key sequences work anymore,
even if I move the focus to a different window with the mouse.

This doesn't seem to depend on what change I make to
xmonad.hs, as long as it causes the compilation to take
long enough. I don't know if it depends on any other factors, such
as KDE configuration, number of windows open and
on what desktops, etc.

>> Besides key presses, other interesting things can
>> happen during a reload. There are probably numerous
>> race conditions lurking here.

>  Can you name some?  I'm not aware of any potential race conditions.

No, that's only a hypothesis. There are many complex things that
can happen during that time. Having already seen that xmonad
and KDE can get confused with each other even when simple events
happen then, it may be worthwhile to think about this carefully.

>  Also, consider using 'xmonad --recompile'.

OK, thanks. Now that I have partially isolated the problem,
I am just avoiding pressing any xmonad keys after mod-Q
until after the red border flashes.

> One minor point: xmonad does catch key events
> while xmonad.hs is compiling, because the
> display is still open.  The only time keypresses
> will get through to the client is between
> initially executing the new xmonad and starting
> initialization procedures.  This should be
> practically instant unless your machine is under
> very heavy load, and I don't think there is much
> we can do about it anyway.

It doesn't seem that way. I can reliably reproduce this,
as long as the compilation takes at least a few seconds.
It doesn't seem to depend on exactly when I press
mod-Q the second time.

I don't really know if the mechanism I suggested -
that KDE gets the keypress and then takes over the
Windows key - is what is happening. Maybe it's
something else.

Thanks,
Yitz