[MUD-Dev] DBs and Events

[Greg Munt]

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.

> Or bottleneck spot caching?

What's that?
 
> :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();
  };

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?

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 feel like I have totally gotten the wrong end of the stick here... 

> 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)...

> 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.

I'm free of Cobol now! Hurrah!

--
Greg Munt, greg at uni-corn.demon.co.uk   "I'm not bitter - just twisted."
http://www.uni-corn.demon.co.uk/ubiquity/