Re: new : iperf servers that stay alive
On 30 Jan, Kevin Gibbs wrote:
> 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.
I did never pretend that Stop() is dead code, only that pthread_exit()
is.
If pthread_exit() is really dead code, maybe you could remove it,
then move the test
if ( EqualID( pthread_self(), mTID) {
from Stop() to the destructor Thread::~Thread() above, and also some
other simplifications could probably follow.
>
> pthread_exit is dangerous when your thread is responsible for allocated
> memory.
and... that's why it's dead code ?
Sorry :-)
> 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.
Agreed (I think this was more or less written in the comments in my
patch)
In fact, it's depending on the inheritance order. But I agree with you
that life is too short to depend on inheritance order.
PS: in any case, a little more verbose comments in the code about these
issues would be far from useless...