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.