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

[Bernhard R. Link]

* Shawn Betts <address@hidden> [080525 10:59]:
> 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?

Often it just terminated with "There can only be ONE". Though
now I no longer get that.

Now it sometimes hangs directly or it reacts one time to C-t but then no
longer and the backtrace is quiberish:
(gdb) bt
#0  0xb7f4c410 in ?? ()
#1  0xbfd11628 in ?? ()
#2  0x00000000 in ?? ()

And of course, often it just works and shows no problems, as you espect
from a well-behaved race condition.

> 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.

Even if cleaning up was atomic, the X server might not yet have noticed
the previous window manager quit. (After all, it has to realize the
socket used by that client was closed, which only happened when the
client terminated and ratpoison got a signal to look after it's child).

> 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.

Yes, something like that must be the solution. At least for the "There
an only be ONE" message triggered here.

Hochachtungsvoll,
        Bernhard R. Link
-- 
"Never contain programs so few bugs, as when no debugging tools are available!"
        Niklaus Wirth