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 wait. > 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 http://www.softpanorama.org/People/Ousterhout/Threads/ 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/