When xmonad needs to recompile xmonad.hs during a reload, that can take time. My machine is a little slow, and sometimes it can be under load. Really weird things can happen In that situation. xmonad seems to be in limbo while the compilation is happening, before the red border flashes. So, for example, let's say I press mod-Q again during that time. I'm using KDE, with Windows as my xmonad mod key. With xmonad in limbo, 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. Very embarrassing! Seems to me that xmonad ought to do the following on reload: 1. Pop up a floater that says "xmonad reloading..." 2. Compile the config module in the background. Meanwhile, keep catching xmonad key events but ignore them. 3. When the compilation finishes, dismiss the floater and restart with the new config. Is this possible? Besides key presses, other interesting things can happen during a reload. There are probably numerous race conditions lurking here. Thanks, Yitz
gale:
When xmonad needs to recompile xmonad.hs during a reload, that can take time. My machine is a little slow, and sometimes it can be under load.
Really weird things can happen In that situation. xmonad seems to be in limbo while the compilation is happening, before the red border flashes.
So, for example, let's say I press mod-Q again during that time. I'm using KDE, with Windows as my xmonad mod key. With xmonad in limbo, 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. Very embarrassing!
Seems to me that xmonad ought to do the following on reload:
1. Pop up a floater that says "xmonad reloading..." 2. Compile the config module in the background. Meanwhile, keep catching xmonad key events but ignore them. 3. When the compilation finishes, dismiss the floater and restart with the new config.
Is this possible?
Besides key presses, other interesting things can happen during a reload. There are probably numerous race conditions lurking here.
Try using: $ xmonad --recompile to fork the recompile job first, then mod-q will just load it. Could you open a ticket to investigate forking asynchronously the recompile process? -- Don
On Sun, Apr 27, 2008 at 06:36:10PM +0300, Yitzchak Gale wrote:
When xmonad needs to recompile xmonad.hs during a reload, that can take time. My machine is a little slow, and sometimes it can be under load.
Really weird things can happen In that situation. xmonad seems to be in limbo while the compilation is happening, before the red border flashes.
So, for example, let's say I press mod-Q again during that time. I'm using KDE, with Windows as my xmonad mod key. With xmonad in limbo, 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. Very embarrassing!
This shouldn't happen. Please give detailed steps to reproduce.
Seems to me that xmonad ought to do the following on reload:
1. Pop up a floater that says "xmonad reloading..." 2. Compile the config module in the background. Meanwhile, keep catching xmonad key events but ignore them. 3. When the compilation finishes, dismiss the floater and restart with the new config.
Is this possible?
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. Also, consider using 'xmonad --recompile'. Cheers, Spencer Janssen
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
On Sun, Apr 27, 2008 at 06:36:10PM +0300, Yitzchak Gale wrote:
2. Compile the config module in the background. Meanwhile, keep catching xmonad key events but ignore them.
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.
Yitzchak Gale wrote:
When xmonad needs to recompile xmonad.hs during a reload, that can take time. My machine is a little slow, and sometimes it can be under load.
Really weird things can happen In that situation. xmonad seems to be in limbo while the compilation is happening, before the red border flashes.
So, for example, let's say I press mod-Q again during that time. I'm using KDE, with Windows as my xmonad mod key. With xmonad in limbo, 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. Very embarrassing!
Seems to me that xmonad ought to do the following on reload:
1. Pop up a floater that says "xmonad reloading..." 2. Compile the config module in the background. Meanwhile, keep catching xmonad key events but ignore them. 3. When the compilation finishes, dismiss the floater and restart with the new config.
Is this possible?
Besides key presses, other interesting things can happen during a reload. There are probably numerous race conditions lurking here.
Thanks, Yitz
Does this happen if any window other than konsole has the focus? It doesn't seem to be reproducible in gnome, so it could have to do specifcally with konsole, or possibly with QT somehow. _____ Justin Bogner
participants (4)
-
Don Stewart -
Justin Bogner -
Spencer Janssen -
Yitzchak Gale