[OT] This feels wrong (pthreads question)

Steve smorrey at gmail.com
Mon Jan 29 08:28:21 MST 2007

Hey thats neat, but I think I've hit upon a much more efficient implementation.
As I said before at present I have it so each sender creates a new
thread and polls the scenegraph on it's own.

After sleeping on it I realized this is far less efficient than
another slightly more complex model.

In this model the whole system becomes event driven.
When my scenegraph recieves an event, it searches itself once for all
objects in scope of the event.  It then notifies all the Sender
objects (we'll call it a client handler for clairty), in scope of the
event, which then take the task of passing it on to the client.

I believe that this would be much more efficient than the current
model, because it eliminates the overhead of a context switch, as well
as the overhead of having each client handler, query the scenegraph on
it's own whether or not an event has taken place.


On 1/29/07, Dave Smith <dave at thesmithfam.org> wrote:
> Steve wrote:
> > By the way, how much overhead does threading actually introduce,
> > especially in a situation where there may be hundreds or thousands of
> > threads in an application?
> You may get to a point where you can no longer spawn new threads, and
> pthread_create() will start to fail and you will have no recourse.
> It still doesn't seem to me like you have explored select()
> sufficiently. select() will allow you to have a single thread (or even a
> small pool of threads) on the server that can handle client requests
> very quickly. If you have multiple cores, use two threads, each
> responsible for a different set of client socket descriptors. Spread the
> most active socket descriptors around evenly between the threads. That'd
> be a fun, and very efficient implementation.
> If your data model is designed right, your CPU will likely never be the
> bottleneck anyway. It'll be the network.
> --Dave
> /*
> 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 mailing list