On Thu, Dec 06, 2001 at 01:50:20PM +1100, James Cameron wrote:
> On Wed, Dec 05, 2001 at 08:23:54PM -0500, Mark Mielke wrote:
> > Considering that much of the code currently references shared memory,
> > I wonder if it would be simpler to use threads instead of processes
> > for ntserv, daemonII, robotII, etc.?
> I favour an event driven model; I've tried threading and it opens up a
> can of worms.  At least select() works on Microsoft Windows.

select() is only implemented for sockets. Microsoft usually uses the
WaitForObject() model with such silly limits as "you can only wait for
64 objects at once."

This is not too mention that an event driven system is a system that
switches in user space. This complicates the code significantly, and
ensures that operations cannot happen asynchronously. 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. 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. 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, 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?

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.

> My point is that the code is already there, it just needs tweaking to
> make it function within a single process.  As Dave says, it's time we
> need.  Or more people.  Given two people, one with C skills, one with
> Java skills, at equivalent experience levels, I'm sure the one with C
> skills would get the job done in a fraction of the time, because the
> code already works.

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

My loyalty to Netrek has to do with the fact that I learned C from
Netrek when I was only around 10 years old. I had read about C, and
played with it for a few years before that, but you need a goal to
strive towards before you actually learn to program. I had such fun
writing my first borg back in those days. I think I spent an entire
summer attempting to perfect it. I realized that its primary weakness
was organization. It is no use if four robots all decide to bomb and
take the same planet. I learned calculus and trigonometry in grade 9
for the sole reason of improving my borg. I wanted better ways to
calculate intercept courses. The standard robot is notably stupid when
it comes to sending torpedoes at somebody orbitting a planet.

Around that time, I started my first job, and time begin to disappear
quite rapidly.

I still owe Netrek something for everything I learned from it. Is it
really 12 years later? :-)


mark at mielke.cc/markm at ncf.ca/markm at nortelnetworks.com __________________________
.  .  _  ._  . .   .__    .  . ._. .__ .   . . .__  | Neighbourhood Coder
|\/| |_| |_| |/    |_     |\/|  |  |_  |   |/  |_   | 
|  | | | | \ | \   |__ .  |  | .|. |__ |__ | \ |__  | Ottawa, Ontario, Canada

  One ring to rule them all, one ring to find them, one ring to bring them all
                       and in the darkness bind them...