thread review (was Re: New file uploaded to boost /)

From: flameframe_at_[hidden]
Date: 2001-09-07 08:48:50

--- In boost_at_y..., williamkempf_at_h... wrote:
> Win32 does gaurantee this.  From the doc for TlsGetValue (emphasis 
> added by me):

Sorry, my fault. 

> > But it is not a serious issue - writing a self-cleaning version 
is 
> > trivial.
> 
> Self-cleaning?

struct thread_object
{
    thread_singleton<whatever> singl;
    void operator() {    ...
};
thread thrd(thread_object);
...
Being destructed thread_singleton reclaims resources. Not an 
universal solution, but does not need an additional dll.

> 
> > > > - implementation of call_once will fail when called function 
> > throws
> > > 
> > > I didn't think about this one.  I'm not sure if we should try 
> > > and "fix" call_once or document that such functions must not 
> throw.
> > 
> > Fix is easy - instead of 
> > 		if (!flag)
> > 		{
> > 			func();
> > 			flag = true;
> > 		}
> > should be
> > 		if (!flag)
> > 		{
> > 			flag = true;
> > 			func();
> > 		}
> 
> Not so easy.  This creates a race condition.  

Could you elaborate ? This section is guarded by mutex.

>Plus claiming that 
> an "init method" has been run, when that method failed, can lead to 
> hard to diagnose bugs.  
>I'm leaning towards the no throw 
> documentation for this reason.

And what if it throws ? Undefined behaviour ?

Let pretend that someone makes an once guard for function that should 
throw. To match the documentation code will be just wrapped with catch
(...){} and became much more error-prone than throwing version.

Throwing exception, especially from complex function, is a most 
useful way to catch the problem. Being restricted to 'no throw' 
programmers will something like static error codes ( as errno ). 

Best regards,
Vitalij.