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
> 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++
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.
Boost list run by bdawes at acm.org, david.abrahams at rcn.com, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk