Well I appreciate the feed back on the overall design model, and I agree, polling a listener instead of setting the listener to blocking, and running it in it's own thread, is probably a bad idea, it's on my list to fix here soon.
The rest of the arguments against threading it this way don't particularly apply as I see it, since the server app is supposed to be running on a multicore or SMP setup. I'ld really, like to maximize CPU utilization, as well as minimizing the amount of bandwidth. The traditional method of the server iterating through a large list of clients just doesn't seem to me to be particularly efficient. Especially if you have different clients interested in different data. Or as in this case you pay once for a server upgrade, but continously for bandwidth. The 250ms sleep time is meant for times when lots of activity needs to be reported to the client, the default could be much longer. But I want to thank everyone for the feedback on the pthreads question which was the crux of my issue. I believe I've found a more compact way of doing what I was doing now. Basically we have the runObject function, but instead of sleeping and calling runObject(data) again, we call a member function run() of the object handed to runObject, and the run() function is self scheduling. So no more thunking after the first time :D Here's a question though, could runObject be handled as a template instead? Seems to me a template would allow it to run pretty much anything handed to it, without the need to change the recast for each object type. Thanks again for the advice! p.s. Is there a better threading library than pthreads? On 1/28/07, Dave Smith <[EMAIL PROTECTED]> wrote:
Levi Pearson wrote: > Well, it's cool that you're trying to build a scalable system as a > learning project, and I think this is a reasonable sort of project to > start with. I think you're getting a bit ahead of yourself, though, > and that you ought to take a couple of steps back and start with > something simpler. If you *really* want to use threads, I would > suggest reading about them in a bit more depth before trying another > design, because your current one is fundamentally broken. If you just > want to build a scalable system, I suggest avoiding threads altogether > and building on top of a select()-based event loop. Levi wrote everything I wanted to write, but I didn't want to spend the time doing it. Thanks Levi! It is *never* a good idea to create a new thread for each user if scalability is a requirement. If you really want to use threads, I would propose a pool of worker threads that can service clients on demand. It'll bound unchecked resource growth and be good experience for you to implement. However, it's going to be a lot more work than a select()-based event loop. What I've found as I've designed systems like this over the years is that the POSIX and UNIX gurus of yesteryear have already thought about all these problems, and have given us a hugely robust set of tools that do what you need. select() is one of those tools. Unfortunately, I'm not familiar with any references that would help you with this, other than the scar-filled memories in my own mind. ;) Along that line of reasoning, this could be a great opportunity to create some scars of your own. At least it's not on someone else's dime. I would actually recommend implementing the system as you propose so you can get a feel for just how problematic it would be. :) Good luck! Let us know how it goes and if you need testers. --Dave /* PLUG: http://plug.org, #utah on irc.freenode.net Unsubscribe: http://plug.org/mailman/options/plug Don't fear the penguin. */
/* PLUG: http://plug.org, #utah on irc.freenode.net Unsubscribe: http://plug.org/mailman/options/plug Don't fear the penguin. */
