[OT] This feels wrong (pthreads question)

Levi Pearson levi at cold.org
Mon Jan 15 15:15:57 MST 2007


Steve <smorrey at gmail.com> writes:

> In this model the whole system becomes event driven.
> When my scenegraph recieves an event, it searches itself once for all
> objects in scope of the event.  It then notifies all the Sender
> objects (we'll call it a client handler for clairty), in scope of the
> event, which then take the task of passing it on to the client.

Now this sounds like a reasonable design, though as you say, it will
require some thinking about your data structures (especially the scene
graph) to do efficiently.  I actually did some thinking about this
exact same design problem, and stopped somewhere around this point, as
I had stopped caring enough about MUDs to progress any further.

Anyway, I was thinking along the lines of storing the objects in a
kind of fractal tree structure in order to simplify finding the
objects within a range, but I didn't get any details worked out.  I'm
sure there's plenty of literature in the 3-d game programming field
regarding this sort of thing.

It starts getting complicated when you consider walls, trees,
boulders, doors, and other such things.  Depending on how realistic
you want to get, you'd probably have to roughly 3-d model everything
and do some sort of ray-casting to see if an object that is in range
should actually be viewable/hearable/etc.

I concluded that it wasn't worth the trouble that it adds to world
building and server coding, and that the 'room' paradigm was good
enough.  I think good writing is more important to MUDs anyway, but
what you're trying to do is definitely cool and is a good programming
exercise anyway, so don't let me discourage you. :)

> I believe that this would be much more efficient than the current
> model, because it eliminates the overhead of a context switch, as well
> as the overhead of having each client handler, query the scenegraph on
> it's own whether or not an event has taken place.

Stick with this design and make your threading model such that there
are only a few threads, and I think you'll be in good shape.  Hundreds
of thousands of kernel threads is just a bad idea, though.  It will
simply not scale well.  I wouldn't go past the hundreds of threads
level at all, and I would definitely try to keep the number of threads
in a small multiple of the number of CPUs, preferably 1 per CPU.

                --Levi



More information about the PLUG mailing list