On 18/01/06, Yann Chachkoff <[EMAIL PROTECTED]> wrote: > > I for one frown on the idea of making the server slower > > There is no reason that it would be slower than it is now. There are no > reason for a modularized system to be slower than the current version. The > only overhead would be when connecting callbacks to objects - and that's > hardly something you'd notice, unless if you're running Crossfire on a > [EMAIL PROTECTED]
Actually, this will depend on how modular the code will be. Going back to Hurd analogy for a second, one of the reasons has not become widely used yet is not because it is modular, but because being so modular makes IPC (Inter-Process Communication) slow (using the GNUMach microkernel), as processes are forced to make frequent calls to the kernel, and therefore the whole thing runs about 66% slower [than Linux]. There is a theoretical design with will make it only 15% slower or so (Hurd on L4), but it seems to have other problems, so the project is no longer sure what kernel it will run on when the Hurd gets released. Effectively, most of the development is spent looking for an architecture that is both modular and fast, and therefore it may look like real "development" is not happening. The same thing can be done to Crossfire, making one "core" module, which will be tasked with starting up, parsing command line arguments, and starting up all other things as modules, provide a way of synchronising them and provide Inter-Module communication. If a message is sent to a module that is not currently there the core would then try to load that module before failing, so the random map generator only gets loaded after someone decides to enter a random map. This feature will also make handling errors easier, so if a person enters a random map, and random map generator is not avaliable, it will be possible to display an error to the player, like "The total chaos inside prevents you from entering". The player could then decide to build and install just the random map generator, and the server would not need to be restarted to apply the changes. Likewise for all other components, so applying a security update will not mean restarting the server. Also if some module segfaults, it will not need a restart of the whole server, but simply of that module. This should aid the server stability, as "something wrong when casting meteor swarm resulting in the spell not working" will not disturb someone else killing dragons in a dungeon. Having the code highly modular also will mean each module can be started as a seperate process (or thread, but that is slightly less portable, if somewhat faster), making it possible to run the server usefully on SMP systems (or even clusters), and therefore potentially much faster than the speed at which the current server runs. I don't know if this is what is wanted, but the advantages seem tempting to me. _______________________________________________ crossfire mailing list crossfire@metalforge.org http://mailman.metalforge.org/mailman/listinfo/crossfire