Re: [boost] Boost.Threads, N2178, N2184, et al
<snip> 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? 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. It is because this issue affects both the C and the C++ community that we can not simply say "we'll leave it up to the others to figure out."
<snip> While strictly speaking I do not *need* to use existing C libraries in my > > C++ code, I *want* to be able to. And I mean this in general, not just for > > threading libraries.> > Ok, so we come again to what seems to be the true heart of the debate. > Do we want interoperability between the C library and the C++ library, > and how much are we willing to pay for it. And it seems we give > different answers to this question. I'm sure you're familiar with the zlib library. It's free, and if it does what you need, would you rather use it as-is, or would you "port" it to C++?
Your friends are close to you. Keep them that way. http://spaces.live.com/signup.aspx
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.
Yuval Ronen wrote:
Emil Dotchevski wrote:
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?
A thread can execute both C and C++ code. The analogy would be a block of memory that toggles itself between 'new' and 'malloc' mode at some arbitrary points, without giving you any indication as to what its current mode is.
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?
It doesn't matter who created the thread; it matters what kind of code it's executing. Unless you never call C code from C++ and vice versa, canceling a thread could prove quite hard. Consider a library with a C interface that is implemented in C++. The C application calls this library from its own thread and then pthread_cancels its thread. The C++ library is executing a call to fread and indirectly, read, which 'throws' a pthread cancelation. The library is left in an inconsistent and unusable state because the destructors of its beautiful RAII guards are not invoked. A few minutes later, when it's reentered, everything collapses. Welcome to a world where C is C, C++ is C++, and extern "C" is a bad joke.
participants (3)
-
Emil Dotchevski -
Peter Dimov -
Yuval Ronen