On Jun 29, 2007, at 12:57 AM, Mike Jagdis wrote: > On Fri, Jun 29, 2007 at 12:39:50AM +0900, bkml wrote: >> >> At present, the show command of the CLI will show objects in load >> order (not alphabetical). I could replicate this behaviour in a >> hashtable without any performance hit by augmenting the hashtable >> with a doubly linked list structure for iteration. > > Danger! Danger, Will Robinson! The module list is in load order > so that reloads happen in the right order. How necessary that is > I don't know but that's what an all too rare comment claims.
The load order only matters for dependencies and if you add or remove a module and then reload, there is no guarantee that the otherwise unaltered load order won't lead to a failure. At present the load order is not necessarily optimal. You can still run into situations where the server aborts the startup because some module was loaded before some other module it depends on. The right thing to do is to let the loader resolve dependencies automatically. In order to accommodate this, module dependency information is required. I had originally added a dependencies parameter to the modules section in the new master configuration file, but I got negative feedback on that from folks who said it would make it more difficult to install third party modules. I then discussed this with those folks (also with coppice) and the consensus was that the module dependency information should be stored separately, one file for each module. I have then removed the parameter in question and instead added a new directory parameter for module dependency files. The idea is to then rework or rewrite the loader to let it resolve all dependencies automatically so that you always get a working load order no matter in which order the modules are listed in the configuration. >> If we wanted the show command of the CLI to produce alphabetic order >> while the CLI remains part of the server, then the server will take a >> serious performance hit whenever the output has to be sorted. >> >> My thinking is that a hashtable augmented with a doubly linked list >> structure for iteration (always returning the load order) is the way >> to go. When the CLI is separated from the server, the CLI utility can >> then be implemented so that it sorts the output alphabetically if >> desired. This way, there will be no performance hit on the server. > > The job of the pbx is to handle calls. Design and optimize for that. > If the CLI has to build its own list and sort it that's its problem. > All the pbx needs to do is dump the needed data out without holding > locks any longer than necessary. Thanks, that's precisely my view, too. However, I'd also like to advocate that any addition to the CLI to produce alphabetically ordered output should wait until the CLI is separated from the server because even without locks, the server is still going to be impacted by any expensive CLI operation for as long as the CLI remains part of it. rgds benjk _______________________________________________ Callweaver-dev mailing list [email protected] http://lists.callweaver.org/mailman/listinfo/callweaver-dev
