[MUD-Dev] Orthogonality and invariants

[cg at ami-cg.GraySage.Edmonton.AB.CA]

[Miroslav Silovic <silovic at zesoi.fer.hr>:]

> 	each path of control that contains mumble(object) must
> 	contain unmumble(object) such that it executes after the
> 	object has been mumbled, and such that there is no other
> 	mumble or unmumble between it and the opening mumble.

That isn't going to work in a MUD. One of the first 'malloc' calls that
the server will see for a new client is that of creating a client
structure for the new connection. That structure doesn't get 'free'd
until the client disconnects. If you create a thread for that client,
then you can arrange to have a nice 'createClient' and 'freeClient'
pair, but not otherwise. Now that player speaks something. That
requires that the text of that speech be sent to all other characters
nearby. That is typically done by making queue elements of that text
that are queued to the output of each nearby player, and into the
input of MUD-run NPC's. Some of those queue elements may not be
processed until after the speaking player has left the game.

> Again you can implement persistence library, one that places each
> loaded object on a list that is guaranteed to get saved before the
> process terminates.
>
> However, there is another, related issue: how to automate object
> loads? If your objects are indirected (i.e. implemented via some
> abstract reference type), you can just check for the load status each
> time you transform the reference to the actual object pointer (Cold
> and MOO do this). You can also use object pointers that point to
> write-protected pages and then load the objects from segfault handler
> (this is done by Texas Persistent Store, and despite the technical
> coolness, it's unfortunately quite slow).

IMHO a better solution is to make your in-MUD programming language be
a persistent programming language. Then the persistence is automatic,
and the scenario programmer can typically ignore it (unless they want
some things to *not* be persistent). Also, it can be done once, in
a general fashion, in the language system and the DB.


> 	for each container, the location of each object within the
> 	container must be the container itself

One could add support for this kind of invariant to the in-MUD language
itself. Not something I've tried, but I don't off hand see any problem
with doing it (other than efficiency).

> 	non-reentrant code should be protected by a mutex

Only if your server is multithreaded. Also, you normally protect data
structures (e.g. objects) with mutex's, rather than code.

--
Don't design inefficiency in - it'll happen in the implementation.

Chris Gray     cg at ami-cg.GraySage.Edmonton.AB.CA
               http://www.GraySage.Edmonton.AB.CA/cg/



_______________________________________________
MUD-Dev mailing list
MUD-Dev at kanga.nu
http://www.kanga.nu/lists/listinfo/mud-dev