[OT] This feels wrong (pthreads question)
smorrey at gmail.com
Sun Jan 28 21:58:11 MST 2007
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
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
Thanks again for the advice!
p.s. Is there a better threading library than pthreads?
On 1/28/07, Dave Smith <dave at thesmithfam.org> 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.
> PLUG: http://plug.org, #utah on irc.freenode.net
> Unsubscribe: http://plug.org/mailman/options/plug
> Don't fear the penguin.
More information about the PLUG