[MUD-Dev] TECH DGN: Re: a few mud server design questions (long)

[Robert Zubek]

Sean Kelly writes:

 > Be careful with threads.  Often programmers consider the best
 > thing since swiss cheeses without considering the cost involved.
 > It takes a measurable time for the operating system to switch
 > processing between threads.  In a pervasively multithreaded
 > program, it's quite possible that you could end up spending as
 > much time switching between threads than you spend processing the
 > threads themselves.  Potential design needs aside, the ideal is
 > still one thread per CPU.

good point. i'm beginning to strongly lean towards a single thread
of execution for the main engine, and handling temporally extended
events via some sort of cooperative yielding. (i have a reply to the
calendar idea in a separate post.)  but i think i'll need still
separate threads for each of the player network interfaces, and
probably one for each of the smarter NPCs (the ones that actually
need to communicate with players - the dumb background NPCs can be
coded up as just objects with an extra bit of autonomy).

 >> in which case the objects' tick handler could be very simple,
 >> and in most cases simply null.
 
 > See above.  No point in wasting processing time traversing an
 > empty function call or checking to see if a pointer is null :)

well, what i'm going for above all is clean and uniform
representation - i'll go to *great* lengths to avoid things like
hard-coding which kinds of objects should receive 'time tick'
messages.  :)

but maybe there's a good middle ground. the idea of having every
object register itself with the container (per joe's posting) could
actually solve most of my problems here...

rob

--
Robert Zubek 
rob at cs.northwestern.edu
_______________________________________________
MUD-Dev mailing list
MUD-Dev at kanga.nu
https://www.kanga.nu/lists/listinfo/mud-dev