Re: Thread: memory leak when using not detached thread?

[Andras Vass]

If this holds true, tcpthread.cpp in the examples is incorrect, since every
myTCPSession is started as a joinable thread and deletes itself without
detaching first.
The same notice should be added to TCPSession::final().

Andras Vass

----- Original Message -----
From: "Gernot Hillier" <address@hidden>
To: "David Sugar" <address@hidden>
Cc: <address@hidden>
Sent: Wednesday, December 11, 2002 9:26 AM
Subject: Re: Thread: memory leak when using not detached thread?


Hi!

On Tuesday 10 December 2002 15:19, David Sugar wrote:
> A thread cannot delete it's own context or join itself.  To make a thread
> that is a self running object that self-deletes, one has to detach the
> thread.

Ok, hope I understood it now. Thx!

Could you add a comment like (slightly modified)

"Note: A thread cannot delete it's own context or join itself.  To make a
thread that is a self running object that self-deletes, one has to detach
the
thread by using detach() instead of run()."

to the explanation of

virtual void ost::Thread::final(void)?

Would be great and help others to avoid the pitfall I stepped in. Thx!

I prepared a small patch for this. See attachment.

> However, there is very definately a known bug in at least some
> glibc releases that when a detached thread exits, it will not clean up
> it's stack frame allocations because that code only existed in the
> pthread_join implimentation, and, of course, one cannot self join...

With using detach() instead of start() and "delete this" in final(), the
resources get deleted here. I use glibc-2.2.5 (SuSE package -164), so I
think
it's fixed in the meanwhile.

--
Bye,

Gernot
"Der Horizont vieler Menschen ist ein Kreis mit Radius Null - und das nennen
sie ihren Standpunkt." (A. Einstein)


----------------------------------------------------------------------------
----


> _______________________________________________
> Bug-commoncpp mailing list
> address@hidden
> http://mail.gnu.org/mailman/listinfo/bug-commoncpp
>