On Thu, 30 Jan 2003, Marc.Herbert --at-- ens-lyon.fr wrote:
> On Wed, 29 Jan 2003, Kevin Gibbs wrote:
>
> > A supported fix for the problem of "pthread_create failed" after handling
> > a lot of clients, is to add the following line:
> >
> > pthread_detach( mTID );
> >
> > immediately following line 118 of lib/Thread.cpp which is:
> >
> > FAIL( err != 0, "pthread_create" );
>
> I still think this change is sufficient only under the assumption that
> the remaining pthread_exit() system call is dead code (that should
> never be enabled again).
The Thread::Stop() has a different function then just ending every thread.
It is only used for untimely stopping (stopping before the thread is done
with its job). Returning from Run_Wrapper is all that is needed to stop
most threads. Stop() is not dead code but is not in mainstream use.
> My patch made an additional "inheritance change" in order to be more
> flexible and allow future evolutions call pthread_exit() again. But
> maybe something I still escaping my understanding of the code ?
> Thanks in advance for any explanations!
>
> More details about this in the comments inside my patch.
pthread_exit is dangerous when your thread is responsible for allocated
memory. In Iperf's case a thread is responsible for the Thread class and
any classes that are allocated along with that (Server, PerfSocket,
Socket, etc). If you call pthread_exit from within the deconstructor of
Thread then it will not release all of these resources. psuedo code
example:
delete() {
for all classes
call decontructor; *
free memory;
}
If you have the thread exit on one of the calls marked with (*) then it
will not get to the free memory part because it will stop executing
instructions. This is not exactly how the delete function is implemented
but it is roughly correct. As such Iperf does not let Stop be called from
~Thread. Once everything is freed the thread is halted by returning from
Run_Wrapper.
> > The other "problems/bugs" were caused by Marc's changes (and possibly
> > fixed as well).
>
> If they were caused by my changes, well... then they surely are fixed
> by your fix, since yours does not include mine :-)
>
> More seriously, what where these "other problems" I introduced ? I
> hope it did not miss some related message on the list...
No, I was saying that your changes caused the inheritance problem and that
your changes (not mine) possibly fixed them as well.
Kevin
PS: Any code in lib/ was originally designed to be a separate library
called libdast (which it still is today, but we do not advertise it).
Which means that not everything in it was designed solely for or used by
Iperf.