[osg-users] [patch] PThread.c++ creation error, lower stack size limit

Cedric Pinson cedric.pinson at plopbyte.net
Mon Nov 30 09:43:41 PST 2009


Hi Robert,

I know you would suggest this solution :). I prefered to use the option
one thread + list of fetch. Because i want to be able to destroy a
thread even if not finished, and it's easy to manage one thread + fetch
list per 'class instance' even if it's consume more thread. It's not
thread that are consuming cpu.

I did not test on windows, the stuff about join() and detach(), so i
guess it would be good to have an advise about it.

Cheers,
Cedric

-- 
+33 659 598 614  Cedric Pinson mailto:cedric.pinson at plopbyte.net
http://www.plopbyte.net


On Mon, 2009-11-30 at 17:23 +0000, Robert Osfield wrote:
> Hi Cedric,
> 
> Thanks for the explanation.  In terms of implementation rather than
> create on thread to create a player I would create one or more
> osg::OperationThread  and attach a single shared OperationQueue
> between them, and then just add a custom osg::Operation to the queue
> when I want an operation done.  Your player loading would then be done
> within a subclass of osg::Operation.  You could even do the database
> loading this way too to enable multi-threading loading.  When the
> OperationQueue is empty the threads just go to sleep and don't consume
> any CPU resources.
> 
> What you are doing is still valid though, and I believe that once an
> OpenThreads::Thread is destructed and it's associated thread destroyed
> all the OS resources associated with it should be properly cleaned up
> - it shouldn't be up to the app developer to go call join or detach.
> One thing we could do is add the extra calls to Thread::cancel() to
> make to it properly clean up.  In the past we've used join() but I
> recall a report of problems with join() on some system - this is going
> back nearly a decade though... and I can't recall the specifics of the
> problem with join().  Lots of happened since then, including likely
> fixes to various Pthread join implementations so it's probably safer
> for us to add it these days.
> 
> Any thoughts from the community?
> 
> Robert.
> 
> On Mon, Nov 30, 2009 at 2:32 PM, Cedric Pinson
> <cedric.pinson at plopbyte.net> wrote:
> > Hi Robert,
> >
> > Ok in my game when i load a ressource i do it in a thread. I dont
> > allocate a thread pool. i just create one thread per load sequence. For
> > example when i create a player i craete one thread with a list of files
> > to load. During the game a player can arrive and leave. So there will be
> > a lot of thread creation and destruction when the game run a long time.
> > It's a simplified view but it's the idea.
> >
> > Without my modification in my code when i created a thread load data and
> > delete it. The thread resource was not clear, it's still valid even if
> > finish. So after one day of game running i had 3Gb of finished thread
> > and deleted but without ressources released.
> >
> > http://www.kernel.org/doc/man-pages/online/pages/man3/pthread_detach.3.html
> > http://www.kernel.org/doc/man-pages/online/pages/man3/pthread_join.3.html
> >
> >
> > I tested two behaviours with join and detach. Both work:
> > If i call detach after the creation of my thread the resources are released when deleted.
> > And if i call join when the thread is finish the resources are also released.
> >
> > http://www.kernel.org/doc/man-pages/online/pages/man3/pthread_create.3.html
> > in the notes section they explain the stuff about the resources.
> >
> > I give pointer to doc only because it explains better than i could, I think
> > you already know those doc.
> >
> >
> >
> > to do the test do something like that:
> >
> > int main(int argc, char** argv)
> > {
> >        {
> >        create 200 threads
> >        run them
> >        when all are finished delete them
> >        }
> >        sleep( 1000);
> >        // check your system memory and virtual memory
> >        return 0
> > }
> >
> >
> > I am not sure if we need to fix this inside osg, i mean calling detach do what is expected.
> > Just user must be aware about this behaviour.
> >
> > I hope i explained correctly
> >
> > Cheers,
> > Cedric
> >
> > --
> > +33 659 598 614  Cedric Pinson mailto:cedric.pinson at plopbyte.net
> > http://www.plopbyte.net
> >
> >
> > On Mon, 2009-11-30 at 10:47 +0000, Robert Osfield wrote:
> >> HI Cedric,
> >>
> >> On Sun, Nov 29, 2009 at 11:02 PM, Cedric Pinson
> >> <cedric.pinson at plopbyte.net> wrote:
> >> > Ok reading the code and the doc of pthread, in order to have the
> >> > ressource freed at the end of the thread, i must call detach(). now i
> >> > have my memory back
> >> >
> >> > maybe it could help for others that create thread in application on a
> >> > long period
> >>
> >> Could you explain a bit more how you are using threads/how you are
> >> finishing them/destructing.
> >>
> >> Is there something missing from OpenThreads Thread destruction?
> >>
> >> Robert.
> >>
> >
> _______________________________________________
> osg-users mailing list
> osg-users at lists.openscenegraph.org
> http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
> 
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 198 bytes
Desc: This is a digitally signed message part
URL: <http://lists.openscenegraph.org/pipermail/osg-users-openscenegraph.org/attachments/20091130/21bc340b/attachment.pgp>


More information about the osg-users mailing list