From: Emil Dotchevski (emildotchevski_at_[hidden])
Date: 2007-03-24 19:33:40
> 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.
>> 2) Does adopting pthreads as the standard lower level abstraction of the
>> <thread> layer make it in any way harder to implement the C++ <thread>
>> layer, compared to an implementation that does not formalize a lower
>> 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
>> 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
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk