[c++-pthreads] concrete library-code example

[Dave Butenhof]

Matt Austern wrote:

> On Jan 7, 2004, at 8:44 AM, Dave Butenhof wrote:
>
>> Gabriel Dos Reis wrote:
>>
>>> Dave Butenhof <David.Butenhof at hp.com> writes:
>>>
>>> | mean it. Perhaps the C++ committee people already know exactly the
>>> | full range of constraints and requirements on this effort, but I, and
>>> | presumably others involved in this wider discussion group, cannot. If
>>> | those constraints and requirements aren't to be explicitly and fully
>>> | shared with us, then the discussion never should have been opened up
>>> | in the first place... and I might as well just go away.
>>>
>>> Well, I would not say that the C++ committee people already know
>>> exactly the full range of constraints and requirements.  I believe
>>> some people have firm opinions on what they would like to have, but
>>> those vary from individuals to individual -- you most certainly saw
>>> disagreements between C++ committee members on this list.
>>
>> Well, perhaps there might have been just a tiny element of 
>> disingenuity in my paragraph; though I'd prefer to call it "tact" in 
>> this instance, that distinction may not really be justifiable. I 
>> really do think that IF there are any predefined requirements and 
>> constraints, either they need to be explicitly layed out for us 
>> "outsiders", or they need to be set aside entirely for these 
>> discussions, because we can't be expected to know them.
>
> To some extent I don't think anyone knows them.  This is a group that 
> consists of people from a lot of different places; some of the people 
> on this list, by no means all, attend C++ committee meetings.

About what I'd expected.

> The origin of this discussion was on the GCC mailing list, when people 
> were trying to figure out how gcc, glibc, and libstdc++ should handle 
> the intersection of C++ and pthreads.  People in that discussion 
> realized that this was a discussion that extended beyond the GNU 
> community and that a solution adopted by gcc/linux wouldn't be nearly 
> as interesting as a solution that was generally recognized as right.

That's encouraging. I guess it also explains the group name, since 
"gcc/linux" would likely be focused on C++ and POSIX threads, regardless 
of any skew between that and the long term goals of the C++ committee. 
So... "Ah".

> In the end, "generally recognized as right" probably means getting 
> approval from the C++ committee and/or The Austin Group.  But that's 
> for another day.
>
> My goals are (I believe) very similar to yours: figure out what the 
> POSIX C binding should mean for C++.  This might mean something as 
> ambitious as coming up with a separate C++ binding, or it might mean 
> making some minor tweaks and clarifications in the existing C binding 
> and/or the existing C++ language specification.  In principle I'm 
> agnostic between the two.  In practice I suspect we don't have the 
> resources or the vendor buy-in to do anything extremely ambitious.

I would like to think that it means a unique C++ binding, because this 
would present far too many unique and useful opportunities to ignore. 
However I also think there ought to be strong compatibility, at least 
"philosophically" with POSIX; especially in areas like cancellation 
where there's substantial POSIX existing practice and virtually no 
existing practice outside POSIX. And most especially considering that 
the kernel and C runtime will need to coexist with both models.

While some changes to the existing C language POSIX specification might 
be necessary, inevitable, or even desirable, the sort of fundamental 
change in cancellation model some have proposed here is a non-starter. 
C++ may be worried about trying to support non-POSIX threaded code 
(though I've expressed several doubts about precisely what that's 
supposed to mean and whether it's relevant), but keep in mind that such 
a fundamental change in the existing POSIX specification would break ALL 
(correct) existing general-purpose POSIX-based threaded libraries, and 
many existing applications. To say such a change would be "contentious" 
would be an absurd understatement. In fact, I would argue that for the 
Austin group to accept such a change would be truly irresponsible. And 
also that for any OS to continue to support POSIX threads while also 
supporting a radically distinct C++ threading model would be onerous and 
impractical. None of this need necessarily serve as a constraint on the 
C++ committee. But then, it doesn't hurt to think about things like 
"vendor buy-in", and that's a lot easier when you're not making radical 
and contradictory requirements.

Of course that's a simplification, because some of the C++ rules and 
idiom around exceptions presents a different sort of contradiction with 
"POSIX compatible" model, and that's not trivial to resolve either. I 
don't mean to discount that, but obviously my focus is more on POSIX 
than on C++, and I can only contribute what I have to contribute.

-- 
/--------------------[ David.Butenhof at hp.com ]--------------------\
| Hewlett-Packard Company       Tru64 UNIX & VMS Thread Architect |
|     My book: http://www.awl.com/cseng/titles/0-201-63392-2/     |
\----[ http://homepage.mac.com/dbutenhof/Threads/Threads.html ]---/