[OT] This feels wrong (pthreads question)

Michael L Torrie torriem at chem.byu.edu
Mon Jan 29 09:04:23 MST 2007

On Mon, 2007-01-29 at 08:28 -0700, Steve wrote:
> 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.

The networking model Dave and others have suggested lends itself very
well to this style of programming.  In fact when you integrate the
select() stuff into the main event loop you've in effect turned network
messages into events that can be handled in a normal way.

Both the GTK+ (Glib with gnet) and Qt libraries both allow you to handle
networking in this fashion.

> 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.
> Thoughts?

Event-driven is, in my opinion, ideal for your application.


> 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.
> > */
> >
> /*
> 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