Threads, IO handling, and Event Queues

[coder at ibm.net]

On 06/03/97 at 07:26 AM, cg at ami-cg.GraySage.Edmonton.AB.CA (Chris Gray)
said:

>First, I'll comment about the goblin-fight and flee example. I don't like
>computer games that ignore my commands. I think I mentioned this when
>Chris L suggested something like it. One of the reasons why people play
>computer games, I think, is because the player is in some ways in full
>control. That will be lost if not all commands are executed, or if things
>are not done in the way the player specified. I wouldn't be surprised if
>some user's reacted very strongly to such things.

This becomes especially iomportant when user commands can launch actions
which persist over time.  As I recall the original example was ala:

  > l
  You are on a narrow spit of land which seperates the lake from the sea.
  > dig canal joining lake and sea
  You begin digging a canal.
  ...much much later...
  You finish digging the canal.

Fairly obviously the user does not want to type commands for every shovel
of dirt heaved, and the above level of gross automation is fairly playable
if a mite boring.  The problem enters when:


  > l
  You are on a narrow spit of land which seperates the lake from the sea.
  > dig canal joining lake and sea
  You begin digging a canal.
  ...time passes...
  Bubba tells you, "I need you.  Come help me quickly!  I'm in Krak's dungeon."  
  > n
  You can't leave until you finish the canal.

Oh no.  That's stupid.  Similarly:

  > n,n,n,n,e,e,w,n,n,w,s,e,d,w
  ...three norths and two easts later...
  There is a vast pile of fabulous wealth here!
  ...w,n,n,w,s,e,d,w...
  There nothing here dumbo.  You already passed the treasure!

There should be a way to interrupt the ongoing process, cancelling all
subsequent commands.  

>As for multi-threading, I would advocate understanding why you want to
>use it, before you devote much time to it. A program with multiple
>threads will run slower on a single-CPU computer than the equivalent
>program without threads. If you truly are targetting speedups by running
>on multiple CPU's, then fine. If not, then reorganizing your server into
>threads had better produce some real improvements in maintainability,
>etc., in order to offset the loss of speed.

This is not entirely true.  A thread can block until a resource is freed. 
A single threaded server can not afford to block, and would thus have to
periodically poll the resource to attempt the waiting action.  Expensies
vary, but MT code can be significantly faster and lighter than ST.  (Note: 
This is often the exception however).

I should also re-iterate for the new clan here that I adopted an MT
approach not for any glaring technical reasons, but more for the same
reasons I've been doing the whole project for the last umpty years:: as a
proof of concept and a method of teaching myself new areas and techniques
that I'm interested in.

>Personally, I believe that moving in the direction of not only threads,
>but multiple co-operating servers is important. Multi-player games will,
>I think, only get bigger, so we will need extra power to run them. It
>isn't going to be easy - that's why there really aren't any good
>distributed MUD servers yet.

Agreed.

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