From: oreillym@tartarus.uwa.edu.au (Michael O'Reilly)
Newsgroups: rec.games.mud.lp
Subject: Re: DISTRIBUTED MUDDING
Date: 17 Dec 1992 17:42:07 +0800
Organization: Home
NNTP-Posting-Host: tartarus.uwa.edu.au
X-Newsreader: TIN [version 1.1 PL6]

Mark Johnston (markkj@muse.cs.mu.OZ.AU) wrote:
: oreillym@tartarus.uwa.edu.au (Michael O'Reilly) writes:
: >how did you handleing multi-threading at the C level? Did you
: >multi-thread the C? Or single thread the C, and indulge in all sorts
: >of horrible code to make it never block? (My way. )
: 
:     Multi-threading at the C level might have been a good idea, but not all
: machines have the threads library.  We're writing this on an SGI which has
: nice things like sproc() calls, etc, but most of the other machines that I've
:looked at do not support this.  The VM's that we are going to use will support
: resource-usage-statistics for the interpreted m-code, so that one can profile
: the execution of the code.  To do this, we're going to just use time-slicing
:for each thread of execution - so basically, we're going for the (potentially)
: horrible code method.

I am doing it the same way (not C multi-threaded). Problems that can
occur. 
Do you support constructors on an object? If so, what happens if the
constructor blocks?? You should switch to a  different thread of
execution , but the C follow of control is like...
	M-code instruction 'add_int' starts executing..
		calls new_object() to hold the result.
			new_object() calls constructor!!! can't do
			this as constructor may block. So
			have to find some way of saveing the C
			state.

What do you do at this point??
What do you do in general if a sub-sub-routine needs to block?? Or
worse yet, call m-code?
 
: >: One of the other
:>: reasons we decided to write a mud was to add a tile-based map system to the
: >: game.  Objects are to have a number representing a 'sprite' number, and
:>:all objects that can contain other objects have a 'map'.  The map represents
: >: the layout of a room, and on top of this, the object sprites are
: >: drawn.
: 
: >It would be nice not to have the driver need to know about this. This
: >is certainly something I thought in the direction of for my driver,
: >but I can't see the driver ever needs to know about it???
: 
: From the point of view of speed, and reducing the complexity of the system
: as a whole, putting all of the graphics handling code into the driver makes
: a lot of sense.  By putting the graphics junk into the driver, it
: 
: (a) removes a lot of time-consuming execution of m-code (which is going
:     to be a lot slower to execute than "proper"-code...)
: 
: (b) stops wizards from making objects that "forget" to call the proper
:     routines in their environment to tell it that it is leaving the room.
: 
: (c) stops the mudlib from having to handle requests for maps.  The clients
:     that will allow players to connect to the driver will cache the maps of
:     each of the rooms, and if a map is not present on the client, then it
:     will send a request_for_map instruction to the driver.  (All maps
:     represent the unchangeable form of the room/object - so they can be
:     cached).  We're not sure at the moment if objects will have their maps
:    set by the code in the ".c" files, or if they will just call an "sys-call"
:    (ie an efun) to set a number in the object structure that represents which
:     number map the object possesses...

Hmm. As my driver is strictly typed I make a distinction between
'driver supported' things, and classes that are implemented in C.

I have things like floating point number routines that are written in
C, but I don't consider them supported by the driver. :) If you wrote
code like...
	Float f = 1.0 , g = 2.0;
	f = f + g;
The driver doesn't need to know about float's in particular. As long
as there is a class called 'Float' that the driver knows about, and as
long as it supports the operations 'assign' and '+', then everything
is fine.

Actually, that is a bad example. The lexical routines do actually
build floating point numbers from '1.0'. But for things like adding
graphics to the driver, you would simply write the class methods in C,
and let it go at that. Nothing else in the driver needs to be modified
to support it.

:     emote looks the other way.
: 
:     I'll second that request for ideas...
Grin.

: >This is simplified is you try and make EVERYTHING an object
: >(includeing code!). This then "simplifies" to sending objects around.
: >No problems.... ;)
: 
:     The way we've "defined" our objects is that an object has two parts to
: it - it's "Intrinsics" (very glamorous, huh?  It took a good wade thru the
: dictionary - the oxford, not the system - to find that one :-) which are 
: all of the physical attributes of the object, and it's "Behaviour" which is
: the code that makes the object do what it is supposed to do...
: 
:     If we start saying that code is an object, and its behaviour is also
: an object, we run into mental recursion problems :-)

Tell me about it. :) The bootstrapping my driver does to build the
first class just ISN'T very pretty. But on the plus side, I let a
large amount of the driver internal structures be objects and it
simplifies my memory management incredibly much.

 
: 	Mark.
Michael