Re: [Ccrtp-devel] Compile error - ccrtp 1.0.0

[David Sugar]

Yes, this is an odd one...I saw the example used involved creating, sleeping, 
and deleting threads in series.  However, the "run" method in the example 
sleeps for 1 millisecond, while the delete method waits in increments of 10 
milli seconds.  So I suspect the thread has already exited into final when 
delete is called.  My suggestion is to retest this with the run method having 
an infinite sleep (sleep (~0)), and the method that starts it off sleep a 
short while and then hit delete.  Thereby delete occurs while still in the 
"run" loop.

I'm going by the example given, with:

        TestThread()
        {};

        void run()
        {
            sleep(1);
        }

and 
                while ( tt->isRunning() ) ost::Thread::sleep(10);
                delete tt;

So he deliberately tries to wait for the thread to exit before joining.  Yes, 
this may indeed be broke since at least some releases of LinuxThread do not 
properly support join (pthread_join) on threads that heave already exited (it 
leaves a 4m virtual page mapped).


On Wednesday 14 May 2003 07:52 am, Federico Montesino Pouzols wrote:
> There is possibly a bug that limits the number of creatable
> threads, though it does not occur on all platforms. It has been
> reported through the bug tracking system of Savannah.
>
> On Wed, May 14, 2003 at 07:35:05AM -0400, David Sugar wrote:
> > In fact, I would like to see 1.0.10 out by the end of the week.  I think
> > the pending issues I was working on related to builds are now closed.
> > There is still a strange problem with redhat and nptl related soley to
> > suspend and resume, but it's not a fatel flaw since all my regular apps
> > build and run.  In fact rh9 is broken since nptl is only fully
> > compatible with kernel late 2.5 kernels (or 2.6), and they still have
> > 2.4 which doesn't fully support it.  But that's another story...
> >
> > I saw we had some new bugs filter through, the most interesting being a
> > memory leak in stringtokenizer.  I think that the win32 thread
> > destructor should delete priv.  Other than that, what else is left?
> >
> > Federico Montesino Pouzols wrote:
> > >   Let's move this issue to bug-commoncpp...
> > >
> > >   I like this idea. Should we release 1.0.10 once we fix the
> > >bugs that are pending, and then go to 1.1.0 (with the new socketport
> > >stuff)?
> > >
> > >On Thu, Apr 24, 2003 at 07:57:31AM -0400, David Sugar wrote:
> > >>Done.
> > >>
> > >>I also have a new and better idea for handling of the socketport
> > >>constructor change (and the other recent 1.0.x changes related to
> > >>macosx).  Let's make the next release from the "RELEASE1" tree 1.1.0
> > >> with the socketport changes, and move "HEAD" into a future "1.9" or
> > >> similar release...This gives a clear delination in release for
> > >> something that will change backward compatibility.
> > >
> > >_______________________________________________
> > >Bug-commoncpp mailing list
> > >address@hidden
> > >http://mail.gnu.org/mailman/listinfo/bug-commoncpp
>
> _______________________________________________
> Bug-commoncpp mailing list
> address@hidden
> http://mail.gnu.org/mailman/listinfo/bug-commoncpp