On Wed, Dec 05, 2001 at 11:38:38PM -0500, Mark Mielke wrote:
> select() is only implemented for sockets. 

Wrong.  I'm using Cygwin.  Anyway, it's not relevant, since it is only
sockets that the server uses.  File I/O can be ignored, in my opinion.

> This is not too mention that an event driven system is a system that
> switches in user space.

What?  The switch has to be done somewhere.  It is much better if it
is under the direct control of the programmer.  More efficient.  O/S
level context switches are by comparison much less efficient, as they
unnecessarily save registers.

> This complicates the code significantly, and ensures that operations
> cannot happen asynchronously.

I disagree.  Even with threads, on a single CPU, only one thing is
happening at once.  The Netrek server can support 20 players on a 486,
at 100MHz, so it doesn't need a dual processor.

> As an example, with the current process model, 16 ntserv processes 
> can be actively waiting for I/O while the daemon process is executing
> code.

A wait is not active.  If I/O completes, the processes become schedulable,
joining the run queue, and while the operating system is entitled to
interrupt the daemon in order to process the I/O, most O/S's do not.
The daemon will relinquish the processor soon.

Now while my experience with operating system design and performance
optimisation techniques is limited to OpenVMS and Linux, I would venture
to say that the Win32 environment can't be terribly bad at this.

> With an event driven system, daemon updates would need to be scheduled,
> and when the daemon was performing an update, I/O could become blocked.

I'm afraid you don't know what you are talking about.  The daemon does the
update in less than a tenth of a second.  We don't need to process the I/O
from the clients during that time, since the results would likely be
buffered by the ntserv for inclusion into the next update.  The data can

> Clients would freeze, and it would all be downhill from there
> as the server tried to 'catch up' every time by building a huge
> select() mask,

64 bits is not an expensive select mask to build.  We're talking machines
at least as fast as a 486/100 here.

> only to throw it away as soon as it realizes: "Hey, 8
> people have data for me." For more real-time systems such as Netrek,
> there is almost always data to be read. Why bother switching yourself,
> when you can let the system do it for you?

Because system switching costs more CPU cycles.  I can guarantee that.
Netrek may look real-time, but by comparison to other real-time systems,
Netrek is very simple and slow.  Only ten updates per second for 20
clients?  Big deal.

> Threading is very neat and tidy. As I'm sure you are aware, Netrek
> already deals with shared memory, which is not really that different
> from the way threads function. The details you would need to fiddle
> with for threads, is that you would want to avoid using signals to
> wake up your threads. Instead, using a conditional, or a wait.

Yes, I know how to thread it, but having been there and done both
threading and event driven models over my (ahem) 20 years professional
programming career, I'm certain that an event driven model would be

- easier to maintain,
- just as effective,
- cheaper to build,
- simpler to debug, (lack of concurrency and race issues)
- more efficient than a threaded model.

Please, could you spare the time to read the presentation by John
Ousterhout, entitled "Why Threads Are A Bad Idea (for most purposes)",
which can be found at


It is only 15 slides.  I've just reviewed it again and concluded:

- Netrek does not need true CPU concurrency.

- Netrek does not need to restrict the developer base by choosing a 
  difficult technology.  We need to do the reverse.

- Netrek is not a place in which we should demonstrate our coding 
  prowess for an examiner.  We're not a training ground.

> I suspect it would take less time to make the server threaded, than it
> would take to make it event driven.

You start on the threading, I'll start on the event driven model.
Show us the code.  Who will judge between us?

I'm worried that you're only discussing this in order to get me to act.
It's a conspiracy.  ;-)

James Cameron    mailto:quozl at us.netrek.org     http://quozl.netrek.org/