bug-commoncpp
[Top][All Lists]
Advanced

[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






reply via email to

[Prev in Thread] Current Thread [Next in Thread]