Random thoughts

[coder at ibm.net]

On 05/04/97 at 06:02 PM, "Jon A. Lambert" <jlsysinc at ix.netcom.com> said:
>This seems to be mail I sent to CL some time ago.  Let me clarify where
>we seemed to going with this.  He probably reposted it with the intent of
>continuing(?). 

Err, yeah, that's right.  Uhh huh.

>> From: Jon A. Lambert <jlsysinc at ix.netcom.com>
>> Date: Saturday, January 25, 1997 5:42 AM
>> 
>> Aye, I have been playing with ColdX/Genesis for the last 2 weeks so
>> this concept is clear to me now.  I've got it running on Linux and have
>> the compiler running on Win95.  I am very close to having the driver
>> running on Win95 :-)

>I went ahead and completed the port.  Brandon Gillespie has made the
>source and binaries available at <www.cold.org>.  I doubt there's much
>interest here, since we are writing our own little messes. ;-) 

I *really* like ColdX as a base design.  Brandon (and Gred Hudson as the
original designer of COLDMUD which ColdX is directly based on (Greg dumped
it on Bandon)) made a lot of very intelligent and well reasoned choices in
the system design.  Its a slick system.  

>My
>impression of this server, Genesis, is pretty good.  It is a very stable
>piece of code and the nice feature which attracted my attention was its
>persistent objects and object caching.  The database is however based  on
>NDBM which is somewhat archaic, low-level, and does not have good
>recovery mechanisms.

My server more than accidentally resembles ColdX is many ways.  Happily
the DB is *not* one of them.  (I support full nested transactions,
rollbacks etc (or will once the current attack on the area finishes)).

>> My first impression of ColdC is much better than LPC.  ColdC seems to be
>> more austere than LPC but just as powerful.

>Further impressions of ColdC led me to believe that this wasn't quite
>what I was looking for in a language.  The inheritance structure has some
>peculiarities and quirks that are not obvious to the new user and can be
>frustrating to a C++ person like myself.  

This is another area I attacked heavily, tho my inheritance model is
probably just another flavour of interesting over ColdX's.  I certainly
don't follow C++'s inheritance model, or any concept of vtables.

>...It is my opinion that complex languages like C,
>C++, Java, LPC and Cold are too difficult to learn by my builders which
>tend to be strictly non-programmers although very creative and smart
>people. My building programs will be GUI editors with nice point and
>click interfaces and the language used by them will be minimal and
>integrated into the building interface.  This will probably end up
>resembling a Visual Basic IDE environment (*giggle*).  Controls which
>represent "black box" C++ programs  can be happily dragged about and
>attached to objects, rooms and NPCs. They will have properties boxes for
>minimal tailoring.  I wasn't kidding about the Visual Mud++ with
>ActiveMud controls concepts!  Lets just hope Microsoft doesn't get wind
>of it, so shhhh!.  Currently my proposed minimal  language seems to
>closely resemble a subset of Fortran with very weak typing  though this
>was not my original intention.  

Now *THIS* is an idea.  I could actually do a whole bunch of this
currently.  Things like spoofs and watchers are really just instantiated
templates with local twiddles.  Changing minor aspects of the rest of the
class structure could....hurm...would not be so easy.

Gotta look at this more.

>Wait, on second thought this might be
>Rexx.  

Mike Cowlishaw is an interesting one to talk to on language design.  A
very opionated, articulate, frighteningly intelligent fellow.  We
disagreed often -- but he had the research data to back his side up.  He
put a lot of thought into REXX's baroque design -- it is and was very
accurately intended as a language for non-programmers.

I've often thought of stealing it almost wholesale as the internal
language for my server.

>> > How does this handle the Dragon's Dinner scenario, ala:
>> > 
>> >   Transaction A checks value X (read, no write, thus no lock), and on that
>> >   basis, changes object Q to state Q`.
>> > 
>> >   Meanwhile, transaction B modifies value X to state X`, and commits prior
>> >   to A committing.
>> > 
>> >   Problem: Logically Q` and X` can't exist at the same time (eg the door is
>> >   closed, _and_ there is a wind blowing through it).
>> > 
>> > It would seem without some checking of read-locks that its a gaping hole.
>> > 
>> Yes Autocommit is useless to your scenario.  Although relational
>> technology does handle this scenario quite well.  In the commercial
>> environment read/locks are avoided like the plague.  I've worked on a
>> number of inventory systems where your 'dragon dinner' scenario can
>> and does occur.  It is generally a risk assesment vs performance issue.
>> Read/locks are really bad if you come upon a wait condition ( ala user
>> input).  The other conditon that comes up frequently is in locking multiple
>> objects.  If you come across an object that is locked by another 
>> transaction you must, in most circumstances, release all your locks
>> and start over or cancel.  Otherwise deadlocks can and will occur
>> between transactions that need to get at 2 or more objects in common.
>> 
>> Now in this particular example, read/locks should work.
>> 
>> 1) dragon and player both attempt to read/lock exit/door object.  
>> 2) first one to the lock wins.
>> 3) If the dragon wins, he releases his lock after he has
>>    traversed the door.
>> 4) If the player wins he releases the lock after the door is slammed.
>> 
>> I would guess if the dragon wins, the player still completes the door
>> closing?  Or you could fail the door slam request based on the failure to
>> get a lock?  If you fail the door slam, do you retry?  It would have side 
>> affects for multiple characters attempting to walk through doors at the
>> same time. 
>> 
>Yikes! This scenario may involve two separate issues.  On one level it
>represents maintaining proper object consistency in a multithreaded
>environment.  And on another level, which I was alluding to is 
>implementing it within the locking mechanisms of a relational database
>like Oracle, DB2, MSQL or Watcom SQL (my currently used DB). Its probably
>a good idea to restart this discussion with some clearer distinctions
>between thread locking and database locking. I am currently pursuing a
>model which includes an Object Manager subsystem.  The Object Manager
>exposes the objects to the rest of the server subsystems and provides the
>object locking, object caching, and disk database access.  Care to give
>it this scenario another go round  Chris or anyone for that matter?

For me there actually is no problem as the general area is resolved by my
lockless/retry model (the old C&C business I detailed, Oh, about 6 - 8
postings ago -- I'll repost if needed.).  Essentially the two events
execute in parallel, but one gets to C&C first and commits, the other then
fails C&C, and retries/reschedules.  This only works becuase all events
only modify and access local data prior to C&C.

--
J C Lawrence                               Internet: claw at null.net
----------(*)                              Internet: coder at ibm.net
...Honourary Member of Clan McFud -- Teamer's Avenging Monolith...