On 12/29/06, Dan Espen <[EMAIL PROTECTED]> wrote:
"seventh guardian" <[EMAIL PROTECTED]> writes: > Hello > > Following Dan Espen's comment on module_interface.h: > > * There really should be a module structure. Ie. the "readPipes", > * "writePipes", "pipeName", arrays should be members of a structure. > * Probably a linklist of structures. Note that if the OS number of file > * descriptors gets really large, the current architecture starts > * creating and looping over large arrays. The impact seems to be in > * module.c, modconf.c and event.c. dje 10/2/98 > > It's now mostly done, except for some tricky details. In annex goes a > diff against current cvs of the work I've been doing. > > It's not finished yet, so it won't compile. The whole module system > needs a cleanup (dup code, hacks, and stuff), specially considering it > wasn't initially meant to use linked lists. My current goal is to get > a working system using the new architecture. More will follow.. > > Please check to see if the work is going in the right direction.. Thanks!Looks like a few sentences turned into a lot of work. Just what I had in mind.
Great :) It already compiles properly, and hopefully there are no introduced bugs. I'll be testing it for some time. TO FUTURE REFERENCE: *There is however one issue: the execcontext.h file needs to know what an fmodule is, so it needs to include module_interface.h. I think this is ugly, but will eventually be cleaned up. Next goals: * separate the module list handling functions from the module communication functions (something like module_list.h/c and module_interface.h/c) * dont use fdsets to store the list of initialization modules. Use another module list instead. * cleanup the module interface functions (remove dup code, etc) The diff goes on annex. I think it is safe now, and hopefully it would make fvwm faster and use a few Kb's less memory :) Please review/test it.. I would really like to see this applied. Cheers Renato
diff
Description: Binary data
