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 -- 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... http://mark.mielke.cc/