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

From: Yuval Ronen (ronen_yuval_at_[hidden])
Date: 2007-03-25 16:06:35

Emil Dotchevski wrote:
>>>> The fact that pthreads exist is completely irrelevant. We setup a C++
>>>> standard, and it should be as good as it gets. The POSIX model is good,
>>>> so we take it. The POSIX syntax is not so good (for C++, obviously) so
>>>> we don't take it.
>>>
>>> What follows then, is that you would like existing pthread C libraries to
>>> continue to be non-portable. I don't see why. I might be blind, but I don't
>>> see why would that be desirable.
>>
>> I never said that. If the C standard committee decides to fully adopt
>> pthreads, I'd be fine with it. And if the C++ standard committee decides
>> to be backwards compatible with C, and also adopt pthreads, I'd be fine
>> with that too. I just don't think it should come instead of "the best"
>> C++ interface, which is what I care about most.
>  
> If pthreads becomes part of C or C++ in its current form, what you'll get
> is that I can write C++ code on pthreads, or C code on pthreads, and it'll
> work. You will not be able to respond in C++ to a pthread_cancel, because
> pthread is a C standard and therefore doesn't specify that pthread_cancel
> throws.
> 
> If all of your code is in C++, you'd know not to call pthead_cancel because
> it won't work. That would be no problem because you can work at the C++
> <thread> level where everything is nice and cool -- but what if a 3rd party
> library built on <pthread> calls pthread_cancel?

Then it would be a very bad library. A library should either create its 
own threads and then it is the responsible to join/detach/cancel it, or 
it works with thread created by the application and then shouldn't do 
any of those things. Just as Howard's example with 
malloc/free/new/delete - what happens if I pass a pointer created with 
new to a library which tries to deallocate it using free? Bad things 
happen. I shouldn't do it, and more than that, such a library, that 
tries to free a pointer not allocated by it, is not a good friend of mine.

> Even today, on non-windows platforms where pthread is standard, we have this
> problem. So this discussion is not about adopting pthreads. It's about
> adopting an extended pthread interface, which specifically deals with C/C++
> interoperability.

I'm really not familiar with the non-windows world. Is it really common 
for a library to call pthread_cancel on a thread not created by the 
application? I've never heard of such thing.