[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Problem in ~Thread()
From: |
Dimitar Dimitrov |
Subject: |
Re: Problem in ~Thread() |
Date: |
Fri, 2 May 2003 17:41:23 +0200 |
User-agent: |
KMail/1.5.1 |
On Friday 02 May 2003 14:57, David Sugar wrote:
> In "RELEASE1", the posix version of Thread::terminate() checks to see if
> priv is NULL before it tries to do anything else, so this should be okay.
> However, the win32 version does not. So this I see as the first problem.
> In fact, from what I see, the win32 version never actually deletes priv or
> sets it to NULL anywhere, which is a different problem. In "HEAD", sure
> enough, priv->_msgbuf is checked in the destructor without verifying if
> priv is valid first. In fact, the priv->_msgbuf freeing code probably
> should be moved into terminate itself before it deletes priv (for posix).
> For win32, priv probably should be deleted at the end of the destructor,
> and appropriate checks added to make sure a NULL priv is not being
> references.
>
I forgot to mention it is in "HEAD". I just saw in the cvs you fixed it ;-)
About moving the cleanup of _msgbuf in terminate() together with other
cleanup code there, it is may be a good idea. I don't know the initial reason
to make this in the destructor so I hesitate a bit to comment here.
Something else:
As we are in thread.cpp anyway can somebody add joinSem.post() in
Thread::close() (in "RELEASE1"). It is in "HEAD" but not in "RELEASE1" so if
somebody tries to join a thread joinSem.wait() hangs.
Regards,
Dimitar