[MUD-Dev] DBs and Events

[Nathan Yospe]

On Tue, 10 Feb 1998, Greg Munt wrote:

:On Tue, 10 Feb 1998, Nathan Yospe wrote:

:> On Tue, 10 Feb 1998, Greg Munt wrote:

:> :Also, any references to caches?

:> Again, can't help you. I've done caches, but not for my mud... and there
:> is such a broad spectrum of things that qualify as cache. Do you want to
:> know more about cached in-memory storage for a disk-based DB? 

:Yes.

The best sources for this would be J C, any of the Cold people, or, if a
member of the DGD development team is still around... was that the LPmud
disk-based project? All I can tell you is, you don't want to be doing it
in the form of frequent access to the disk, so if you can find a way for
the data to reside in memory for a while after any read, and for data to
be held for writing until a significant chunk of contiguous memory is in
the cache, you're better off. Hopefully others can advise better than I.

:> Or bottleneck spot caching?

:What's that?

An element of assembly coding and RISC compiler design. It might also be
significant for VM construction. It has to do with the repeated register
loading of the same data over and over. Essentially means finding where,
when, and how information can be loaded onto the stack/into registers to
minimize the number of loads (This opposed to operational instructions.)

:> :Any references to Event Management? Is there any alternative to using a 
:> :pointer to a function, to store the Event->function()? (This has the 
:> :disadvantage of every Event->function() needing to have the same number 
:> :and type of parameters being passed to it.)

:> Here we go. This I can help you with. Events don't have to be functions,
:> for a start. An event could be stored as anything, from a script on down
:> to a held thread. I store mine as classes... any action is executed from
:> an event class, which grabs the nearest available execution thread, sets
:> it to the event's references, and frees it to go. Events are, by design,
:> only actually capable of grabbing one specific thread, such that any set
:> of events cannot execute asynchronously on the same resources. Functions
:> are actually pulled up _after_ execution begins... Event.Process() is at
:> its basis a normalization check, which tries to match a list of objects,
:> and upon success, changes the values of the objects to a new norm, then,
:> with its still-active thread, allows those objects to update. The object
:> update methods are the actual functions involved, and once each object's
:> updates are complete (and affected objects with zero delay complete such
:> updates as the modified objects have made available) the thread is wiped
:> clear of variables, set to sleep, and returned to the pool. 

:I'm not sure I understand this too well. Are you suggesting this?

:class Event
:  {
:     private:
:       DataType1 *a;
:       DataType2 *b;
:       ...
:
:     public:
:       ...
:       process();
:  };

class Event{
  SortedList<ObjectReference<BaseObject>, PrioriList<AttributeType,
      AttributeValue> > objectList;
  TimeValue  timeCheck; // for purpose of sanity checks
public:
  process(); // set values... for each object in objectList, call
             // BaseObject::update();
};

:I still can't see how the event isn't a function. The tasks that the 
:event does have to be stored in a function?

Well, yes and no. I operate entirely on the principal of creation, value
modification, full instantiation, partial destantiation, and deletion. I
don't tolerate the sort of procedural functions that most languages use.

:Am I wrong in thinking that the data that an Event needs (eg pointer to a 
:Player) are stored in the class, with a function - which takes no 
:parameters - calling class methods to do whatever it is that the Event is 
:trying to achieve? Also, it looks like Event would need to be a template. 
:Forget that, am using Linux g++ :(

I'm using g++ too... so far, the templates haven't bit me. Not Linux, if
that makes a difference, but still. I know that some of the advanced and
esoteric template functionalities, g++ won't work. Nevertheless, there's
no reason I couldn't have done without, aside from my pointer and Lists.

:I feel like I have totally gotten the wrong end of the stick here... 

Nah. You'll learn. Give it some time. Use Java for a while, if you want.
It is crippled, but you learn a lot from programming with it. Seriously.

:> This is just
:> one approach to events that doesn't actually require a function pointer,
:> and a good number of others can be found in deja news archives of thread
:> and event related newsgroups.

:Could you lead me in the right direction here? Searches on dejanews 
:revealed not very much (read: nothing)...

Can't remember the ngs right now myself, but... I'll take a look Friday.
Got work and school until then, so I'll be a bit too busy. Can you hold?

:> Nathan F. Yospe - Aimed High, Crashed Hard, In the Hanger, Back Flying Soon
:> Jr Software Engineer, Textron Systems Division (On loan to Rocketdyne Tech)
:> (Temporarily on Hold) Physics student, University of Hawaii dept of Physics
:> yospe at hawaii.edu nyospe at premeir.mhpcc.af.mil http://www2.hawaii.edu/~yospe/

:I'll use this opportunity to keep you updated on my work activities: I 
:finally got a job, C++/Unix, using such tools as Rational Rose, etc. I'll 
:be maintaining and developing planning and scheduling software for the 
:steel industry. Will post a FAQ update soon.

Congratulations. Rational Rose, eh? I have misery in my company. I mean,
company in my misery. No the first time was right. We use Rose too. Dang
piece of ill concieved code. Powerful, though. But... how can a tool for
object oriented design be so... inconsistant? It seems to have spaghetti
for innards, and the user interface changes from one tool to the next so
radically that the keys for _copy_ and _paste_ are never the same, and I
don't even want to go into the deletion and selection procedures. Bleah!

:I'm free of Cobol now! Hurrah!

That must be a relief. Congratulations again, and here's hoping it stays
good. BTW, sounds similar to myself, except mine was Fortran. C++ RULES!

--

Nathan F. Yospe - Aimed High, Crashed Hard, In the Hanger, Back Flying Soon
Jr Software Engineer, Textron Systems Division (On loan to Rocketdyne Tech)
(Temporarily on Hold) Physics student, University of Hawaii dept of Physics
yospe at hawaii.edu nyospe at premeir.mhpcc.af.mil http://www2.hawaii.edu/~yospe/