Emil Dotchevski wrote:
Here is how I understand your question: does it make sense to formalize a lower level API behind <thread>.
You understand correctly. This is the question I ask, and the answer I give is "no".
If we lived in a world where pthreads did not exist, I wouldn't care much one way or another; but we don't.
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.
<snip>
2) Does adopting pthreads as the standard lower level abstraction of the C++ <thread> layer make it in any way harder to implement the C++ <thread> layer, compared to an implementation that does not formalize a lower level interface?
3) Does a formal pthread layer introduce any overhead in the higher level C++ <thread> layer?
I haven't checked it in depth, but if you say no, then I'll take your word for it.
I haven't checked in depth either. But I'm very interested to know the answer.
In particular we need to examine the answer to 2) and 3) wrt the Windows <thread> implementation, since on Posix the answer is clear.
Disagreement again. Question 1 is not to be overlooked at all. The C++ moto is "don't pay for what you don't need". I'll add to that "don't standardize what you don't need". Less is more, and stuff like that.
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. Emil Dotchevski