Re: [boost] Boost.Threads, N2178, N2184, et al

From: Howard Hinnant (hinnant_at_[hidden])
Date: 2007-03-26 11:21:36

On Mar 26, 2007, at 1:32 AM, Alexander Terekhov wrote:

>
> Howard Hinnant wrote:
> [...]
>> got a problem there.  Indeed maybe even a bigger one:  fclose is
>> allowed to throw! :-\
>
> That just means that you'd either have to deal with it (disable cancel
> at places where you don't want it to throw, or catch and self-re- 
> cancel,
> or whatever) or just declare your code cancel unsafe (your clients  
> will
> either disable cancel or simply won't cancel at all) and be done with
> it. Given that the later is the current state of affairs in today's
> (p)thread/C++ world, what the heck is the problem?

Perhaps just one of education.

I'm a cautious person and strive to fully consider the ramifications  
of all the decisions we're making.  It seems to me that the more  
cancellation points we introduce, the more complicated the interface  
becomes that we're introducing.  We tentatively have cancellation  
points to introduce in two categories:

1.  New functions that haven't before appeared in the standard:
     thread::join
     this_thread::sleep
     etc.

2.  Existing functions that acquire this new functionality of  
cancellation point:
     fclose
     fflush
     fgetc
     fopen
     fprintf
     etc.

Set 2 worries me more than set 1.  If no one else sees any problems I  
might be tempted to write it off as me being overly cautious (again).   
But the last time I got LWG direction on this very subject, they were  
much more agreeable to set 1 than set 2.  That could change of  
course.  Perhaps we all just need a little more thought and  
education.  Or perhaps our caution is warranted.

-Howard