Fun with Erlang (was Re: Stand Alone Erlang for Windows. yet again)

[Alexander Williams]

On Fri, Mar 16, 2001 at 03:30:32PM +0100, Ulf Wiger wrote:
> This can be done, as long as one doesn't make any assumptions about
> Pid (it will change), and there's a stable state in which to do this.

So, we end up needing another unique ID system.  (Gensym, come home,
all is forgiven!)  I'd really like to shy away from the
MU*-traditional form of just increasing integers, but ... it is simple
and effective, I suppose.

> AXD301 for handling connection setups (the problem there is that we
> can't have one process per connection, as there are too many
> connections.)

Right, an advantage that a MU* has, typically only having to deal with
10-20 "real people" at any given time, and on the high-end, 300-400.
While MMORPGs often have 10,000+ folks on, I think we'll go a little
lighter on expectations.  :)

> I once toyed with the idea that you could mirror a process to 
> another erlang node in real-time, e.g. using something like Encore's
> Reflective Memory technology (http://www.encore.com). Then, you'd
> have to introduce some 'passive' state for the process replica.
> I couldn't get a clear mental picture of the repercussions, so I
> dropped the idea. I imagine really dumping processes to disk would
> have some similar repercussions.

Exactly.  Its handled in a couple different ways in current MU*
environment, sadly, areas I'm less expert than I'd like to be.  I
recall POO, owing to its Python OOP nature, simply marshalls up the
objects with their attached state to disk, and upon restart, loads
everything back up before init'ing it (so references from a live
object from a yet-to-be-restored don't happen).  Unfortunately, that's
no so much an option here.  I /really/ should take a closer look at
how LP does it; LP's objects are written in a C-variant, so they can't
really just be "marshalled up," I suppose.

One advantage of going an LP-esque route would be the actual Thing
sourcecode would be saved externally to the database itself.
Hmmmmmm.  Maybe it would be enough to impliment a {dump} routine on
each Thing which takes the state-tuple its passing to itself on each
loop as well as the process dictionary and packages it up along with
where its source-file lives, then puts it in the database.  You'd need
a similar {restore} method that wakes it back up as an instance after
being pulled back out of the database, and probably an {initialize}
just to get it started back up in the first place.

Challenging problem.  Thank Hades we have ETS already as a decent
databasing system built in.  That's 3/4ths of a major MU* design
nightmare right there.  I do sort of miss Python's Dictionaries, a
sort of lightweight hash/array that maps an immutable value to another
value, but ...  I think we'll deal.

-- 
Alexander Williams (thantos@REDACTED)               | In the End,
  "Blue Jester needs food."                             | Oblivion
  "Blue Jester needs fuku-wearing cuties."              | Always
  http://www.chancel.org                                | Wins