Re: CThread & polite mode

["Ilya A. Volynets-Evenbakh" <ilya@total-knowledge.com>]

Well,
It's about time we go back to exploring this issue.

I'm doing some testing in CPPSERv, and it's obvious that if we don't 
make the changes,
nothing is going to work right.

I think I'll go ahead and get rid of m_waiter lock alltogether and 
replace it with pthread_join
for *nix, and put big fat error message for Winblows, so that everyone 
who runs threaded code
knows to bug you to fix polite thread destruction there.

OK?



Alexey Parshin wrote:

> It could be WaitForSingleObject(), but I'm not sure. I just never explored it.
>
> On 5/21/05, Ilya A. Volynets-Evenbakh <ilya@total-knowledge.com> wrote:
>  
>
> > Alexey Parshin wrote:
> >
> >    
> >
> > > Not that I know of ..
> > >
> > >      
> > Are you saing there is not way to say "block till thread completes"
> > natively??
> >
> >    
> >
> > > However, in Windows CThread is an object, and I
> > > wonder how WaitForSingleObject would work with the thread.. It could
> > > be an idea.
> > >
> > >
> > >      
> > You really need to investigate that.
> >
> >    
> >
> > > On 5/21/05, Ilya A. Volynets-Evenbakh <ilya@total-knowledge.com> wrote:
> > >
> > >
> > >      
> > >
> > > > I think polite mode (at least on Unix) should be handled by
> > > > pthread_join, and not the CWaiter.
> > > > Is there similar concept in Winblows?
> > > >
> > > >
> > > > Alexey Parshin wrote:
> > > >
> > > >
> > > >
> > > >        
> > > >
> > > > > I do use self-destruction sometimes. However that conception is
> > > > > limiting us too much. It
> > > > > should be another solution.
> > > > >
> > > > > In the worst possible case, we can drop onThreadExit() whatsoever.
> > > > >
> > > > > On 5/20/05, Ilya A. Volynets-Evenbakh <ilya@total-knowledge.com> wrote:
> > > > >
> > > > >
> > > > >
> > > > >
> > > > >          
> > > > >
> > > > > > I've been thinking about CThread::onThreadExit() function,
> > > > > > and realized there is race condition there:
> > > > > >
> > > > > > thread a creates and starts thread b
> > > > > > thread b is executing
> > > > > > thread a calls b.terminate()
> > > > > > thread b finishes executing threadFunction
> > > > > > thread a destroyes thread b object.
> > > > > > thread b.onThreadExit() starts executing
> > > > > >
> > > > > > This will happen even in polite mode, I'm afraid, since
> > > > > > onThreadExit is called after m_waiter is unlocked.
> > > > > >
> > > > > > The only way to make sure this doesn't happen, that I can think of right
> > > > > > now,
> > > > > > is to impose "self-destruction" paradigm on CThread-derived objects.
> > > > > > i.e.
> > > > > > 1. CThread is always created on heap
> > > > > > 2. CThread objects are never explicitly deleted.
> > > > > > 3. there is onExitInternal() handler, that is called after normal
> > > > > > onThreadExit() is called,
> > > > > >  and that does "delete this".
> > > > > >
> > > > > > This is serious change in usage paradigm, so before going ahead and
> > > > > > making such
> > > > > > a radical change, I want to know what you think about it all.
> > > > > >
> > > > > > oO(Perhaps HSquirrel is already using self-destuction paradigm anyways,
> > > > > > like I do?)
> > > > > >
> > > > > > --
> > > > > > Ilya A. Volynets-Evenbakh
> > > > > > Total Knowledge. CTO
> > > > > > http://www.total-knowledge.com
> > > > > >
> > > > > >
> > > > > >
> > > > > >
> > > > > >
> > > > > >            
> > > > --
> > > > Ilya A. Volynets-Evenbakh
> > > > Total Knowledge. CTO
> > > > http://www.total-knowledge.com
> > > >
> > > >
> > > >
> > > >
> > > >        
> > >
> > >
> > >      
> > --
> > Ilya A. Volynets-Evenbakh
> > Total Knowledge. CTO
> > http://www.total-knowledge.com
> >
> >
> >    
>
>
>  

--
Ilya A. Volynets-Evenbakh
Total Knowledge. CTO
http://www.total-knowledge.com