[MUD-Dev] Re: Why modules? (Was: Inheritable modules)

[Vadim Tkachenko]

Ola Fosheim Gr=F8stad wrote:
>=20
> "Jon A. Lambert" wrote:
>=20
> > I mentioned in an earlier post about not having a core but a set of
> > modules that together implement core functionality....so in that
> > vein...
>=20
> Sounds a lot like a mud-oriented library which I suggested quite early =
on.
>=20
> > Why couldn't each module implement it's own desired level of
> > threading.  The loader would dynamically load the module and then
> > start it running using a createthread(), startthread() mechanism.
>=20
> Can someone please explain WHY dynamic loading is desired?  I haven't s=
een
> one good argument yet for why it should be dynamic.  People won't repla=
ce
> their magic module twice a day. Probably not once a month either, a reb=
oot
> once a month is quite good!

One of other threads discussed the drawbacks of the downtime. From my
standpoint, this is exactly it: the point of having the dynamic loading
is to eliminate the downtime.

It's a Windows world concept (don't start a religious war here, please)
that you have to reboot as soon as you do anything more offensive than
renaming a file. With a proper design (note, done once) it's possible to
dynaload everything else up to dynaloader code, then you don't need to
shut down the server to upgrade.

The alternative is multitier system with a parallel processing which can
allow you to switch the load off the module and shoot it down (provided
the old and new versions of the module are compatible). But as for me,
cost of creating such a beast (not even hardware, which fades in
comparison to development) is hardly less than a dynaloader.

> Here are some good reasons for making it static:
>=20
> 1. easier to implement
> 2. more portable

With the proper abstraction levels, it's not a problem. I don't see how
the static module is simpler if the dynamic one is wrapped and has no
clue about it being dynamically loaded at all. Take look at Apache
design (I'm not saying it's done this way, though).

> 3. faster

On startup? How many times do yo boot it?

> 4. more likely to be reusable in other (non-DevMUD) systems

Absolutely disagree.

> 5. allows for GLOBAL compiler optimization (on SGI for instance). This
>    could be an advantage if you have a lot of traffic crossing object
>    file boundaries.

Could agree here.

[skipped]

> Maybe a 20% speed up isn't all that much, but have 4 levels of 20% spee=
d=20
> ups and you'll have a 100% speed up!

Hold on a second... You sure? ;-)=20

Actually, out of curiosity, three lines in Perl give:

0:      120
1:      144
2:      172.8
3:      207.36
4:      248.832
5:      298.5984
6:      358.31808
7:      429.981696
8:      515.9780352
9:      619.17364224

So you were off 7.36% ;-)

Mo cookie file contains this entry:

%
The First Rule of Program Optimization:
        Don't do it.

The Second Rule of Program Optimization (for experts only!):
        Don't do it yet.
                -- Michael Jackson
%

> Ola

--=20
Still alive and smile stays on,
Vadim Tkachenko <vt at freehold.crocodile.org>
--
UNIX _is_ user friendly, he's just very picky about who his friends are