[MUD-Dev] resource management (was: Missing the point)

Felix A. Croes felix at dworkin.nl
Wed Oct 28 16:38:47 New Zealand Daylight Time 1998

"Bruce Mitchener, Jr." <bruce at puremagic.com> wrote:

> On Tuesday, October 27, 1998, Chris Gray wrote:
> >[Bruce Mitchener, Jr.:]
> >
> > >for x in [1 .. 100000000000000] {
> > >        /* don't run out of ticks */
> > >        refresh();
> > >        y += "aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa";
> > >}
> The problem isn't execution time.  The problem is that 'y' will soon be very
> large and handling out-of-memory situations is difficult.  Right now, if
> Genesis runs out of memory, it shuts down.  This is obviously non-optimal.
> This isn't an issue of imposing a maximum size on a data stored by a
> variable, since someone could just create lots of variables.  That continues
> on up to task-groups.  I'm trying to find a nice way to handle
> resource-accounting where as little of it is in the driver as possible, but
> is still extensible by the DB code.  Even with this, there are problems.  If
> quota-tracking (how many bytes of objects a user may have), then one could
> bloat up some objects and bring them into memory to trigger an out-of-memory
> condition.
> This greatly affects the security of a system that allows for free-user
> programming.  As far as I know, MOO has this problem as well.  I don't know
> about Muq, DGD, or MudOS.

It is worse for DGD, because DGD has shared arrays.  During execution
of an LPC thread, they may even be shared between objects -- only if
no LPC code is currently executing does the server know which object
data belongs to.  Maintaining a notion of ownership during execution
is possible (counting datastructures shared by two objects as
belonging to both) but would involve considerable overhead.

I could just replace shared arrays by unique ones a la MOO, but I
like shared arrays.  They are useful for self-referential
datastructures, among other things.  Also, I suspect that in
moderately-complex mudlibs, some form of shared data would creep
back in on a higher abstraction level, one way or another.

> Am I just missing something obvious?

I think the problem is actually hard to solve properly.  I have
not even attempted to deal with it, yet.  I did work on managing
other resources, see


Felix Croes

More information about the MUD-Dev mailing list