From: Yuval Ronen (ronen_yuval_at_[hidden])
Date: 2007-03-24 18:44:18
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.
> So I think you're asking the wrong question.
I disagree. I think the question I'm asking is spot on, really. ;-)
> I think it's more appropriate
> to ask ourselves:
>
> 1) Given that pthreads is already a very solid formal standard, and given
> that there is a lot of legacy code already written for it, does it make
> sense to also formally standardize it as the abstraction layer of the C++
> <thread> support?
Sorry, but I think not.
> 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.
> 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.