Well, I have a patch that doesn't really fix things, but lets me work
around the bug that (so far) only bothers tkgoodstuff.
I've tracked down the bug: the race condition happens when a few
instances of tkgoodstuff have left child processes when they exited.
Fvwm doesn't notice that the tkgoodstuff instances are gone until
until the child processes (of the dead and gone tkgoodstuff processes)
exit. The race condition goes away when the child processes exit (at
that point, the call to KillModule gets made).
This doesn't happen with FvwmButtons because FvwmButtons doesn't fork
children (but tells fvwm to).
I don't know if there is any better way of sensing module death than
the one fvwm currently uses. If there is one, it would be best to use
it, of course. But in any case, one workaround that would make me
happy would be for fvwm to allow a module to tell fvwm to kill it.
Here's a patch that allows this (the module sends "KillMe"):
*** ../fvwm-2.0.42/fvwm/module.c Tue Apr 2 11:53:31 1996
--- fvwm/module.c Mon May 27 11:53:28 1996
***************
*** 304,309 ****
--- 304,315 ----
extern int Context;
FvwmWindow *tmp_win;
+ if(mystrncasecmp(text,"KillMe",6)==0)
+ {
+ KillModule(channel,12);
+ return;
+ }
+
/* If a module does XUngrabPointer(), it can now get proper Popups */
if(mystrncasecmp(text,"popup",5)==0)
Event.xany.type = ButtonPress;
I hope you (Chuck) will consider this.
Thanks, and bandwidth apologies,
Mark
--
Visit the official FVWM web page at <URL:http://www.hpc.uh.edu/fvwm/>.
To unsubscribe from the list, send "unsubscribe fvwm" in the body of a
message to majordomo_at_hpc.uh.edu.
To report problems, send mail to fvwm-owner_at_hpc.uh.edu.
Received on Mon May 27 1996 - 11:36:28 BST