[MUD-Dev] Re: TECH: Distributed Muds

[Steven Fleischaker]

<EdNote: I've fixed the quote and inserted leading quote characters as
per http://www.kanga.nu/lists/listinfo/mud-dev/ (you got lucky as a
first poster)>

From: J C Lawrence

> I've never liked the base concept of a select() looping process that
> tried to do real work between select() calls.  It can work to be
> sure, but it has always smelled of playing with fire.

> I prefer having a thread dedicated to socket IO, pulling in and
> buffering the IO as received, and then handling compleated blocks
> off to one or more queues (depends on whether you do pre-sorts) for
> the other game systems to pick up and process appropriately.  There
> are several advantages, not the least of which is that you decouple
> your command/entry model from your processing model.

Unlurking because this interests me.

The little exposure I've had to multiple threads has left me feeling
that working with multiple threads is like building a swiss clock.  If
you don't have some idea of what you're doing, get it just right, then
the gears start to mesh, you start hearing grinding noises, and your
app or your whole system just crawls.  I played with it, got some
things out of it, mostly have a few books sitting on my shelf for when
I have the time to invest in learning how to do it well.

Is there some semi-optimal or conventional approach to handling this
sort of thing?

ie.

  1> start a listen thread (listen for new connects, process IO) for
  all channels OR start a separate thread for each connection?

  2> start (a) main game thread(s)

  At intervals (guidelines for responsiveness.. 10 ms?) enter/use
  critical sections to cause both threads to synchronize, swap
  information, exit critical sections/let each thread go their merry
  way?

Do you keep all the IO buffers in one thread, or do you keep buffers
in both threads?

In Win-NT/2k is there an optimal way to halt a thread, pause N
milliseconds in clock time, then pick it back up without bogging your
thread down in endless calls to a time command?

I could design a control algorithm to track 1-second intervals but it
strikes me as overkill.

There are some amazingly nasty things I've managed to do in the past
with binary trees and poorly synchronized threads.  Also, at least in
Win-NT, there don't seem to be a lot of inexpensive, thread-safe
databases.

I've got a very nice book on this, am just curious what people have
seen and how it worked for them.

Lurk Mode back on.

_______________________________________________
MUD-Dev mailing list
MUD-Dev at kanga.nu
https://www.kanga.nu/lists/listinfo/mud-dev