On 8/21/07, Dominik Vogt <[EMAIL PROTECTED]> wrote: > On Tue, Aug 21, 2007 at 01:42:08PM +0100, seventh guardian wrote: > > On 8/21/07, Dominik Vogt <[EMAIL PROTECTED]> wrote: > > > On Tue, Aug 21, 2007 at 01:57:40PM +0200, Dominik Vogt wrote: > > > > With this minimal .fvwm2rc fvwm hangs in startup for many seconds. > > > > > > > > ----------- BEGIN .fvwm2rc ----------- > > > > ModuleSynchronous Timeout 5 FvwmTheme > > > > ------------ END .fvwm2rc ------------ > > > > > > > > I think something is broken in the module code. Since it waits > > > > longer when more commands are added, fvwm may run into the module > > > > timeout repeatedly (but maybe not). > > > > > > The attached patch is responsible for the bug. It was committed > > > between 2007-08-05 23:00:00 and 2007-08-05 23:30:00. > > > > > > > I think I overlooked the importance of that code. My fault. > > > > There are two alternatives now: > > * correct the situation using the current multiple list mechanism > > (I'll try to do that today) > > * reintroduce the flag mechanism right away > > > > I'm not sure about which one is better now, but I can only look > > at it tonight.. > > I see. For now I have rewritten that code so fvwm runs without > hanging for me.
Ok, thanks. (and sorry for the fuss..) > Can you elaborate on the new design of the module code a bit? * First of all, modules are unaware of the list mechanism. The fmodule struct just stores the module data, nothing more. There are functions for the module allocation/deallocation, etc. * Module lists are transparent containers. There are functions for their handling (functions for adding and removing modules, list iterators). There can be multiple lists (currently only two: working modules and a "death row" for dying modules). On top of that (hopefully) clean mechanism there are the "old style" fvwm functions. These functions make the new mechanism look like the old one to the rest of fvwm. There is the "module_kill" functions which moves a module from the "working" to the "dying" list, or the "module_clean" which destroys the dying modules in a safe place (empties the "dying" list). These "old style" functions hide the existence of multiple lists from fvwm (to avoid big and dangerous changes). I believe it would be good to expose the mechanism (maybe after the release). Also, the distribution of functions among .c files is not done properly (another thing to be done after the release). Finally, this mechanism could easily support more lists, as a way to differentiate modules (selective broadcasts, message masks, etc). There could also be a different list for different kinds of modules (one for piped modules, other for .so modules, etc..). Cheers, Renato
