Re: [RP] race condition when tmpwm returns too fast

[Shawn Betts]

On Fri, May 2, 2008 at 2:08 AM, Bernhard R. Link <address@hidden> wrote:
> Ratpoison seems to have problems regaining control after an tmpwm if
> that tmpwm exists to fast.  The problem was found by Bruce V Chiarelli
> and reported to the Debian BTS as http://bugs.debian.org/478979.
>
> I can only reproduce if I kill the window manager run via tmpwm
> manually. Also ratpoison is not always in an unresponsive state,
> I also get "ratpoison: There can be only ONE." messages sometimes.
>
> My guess is that this is a timing problem. While ratpoison uses XSync
> in cmd_tmpwm, that only syncs itself and does not make sure the X server
> realizes the other window manager is gone already.

This sounds like 2 problems rolled into one. Can you get a backtrace
when it becomes unresponsive? Is it spinning in some tight loop
waiting for a child to return or something? Or is it waiting for an X
event suggesting that it hasn't properly grabbed the top level keys?

In the case of ratpoison taking control too quickly, that's a tricky
one. Seems like the tmpwm program has quit but X hasn't finish
cleaning up after it and then ratpoison requests substructureredirect
on the root window and it errors out. You would sort of think cleaning
up after a client would be atomic, though. Perhaps the thing to do is
to install a custom error handler that sets some global variable, and
then try to select the substructureredirect, call Xsync, and then
check if the global var is set (an error occurred), if so sleep half a
second and try again.

-Shawn