Re: [Boost-Users] Re: boost::mutex::scoped_lock conventions

From: William E. Kempf (wekempf_at_[hidden])
Date: 2003-05-20 09:13:04

Alexander Terekhov said:
>
> "William E. Kempf" wrote:
> [...]
>> >> BTW: If the above functions are what I think they are, I can
>> provide them in Boost.Threads with out anything being changed in
>> the POSIX standard.
>> >
>> > We need a POSIX.C++ standard, that's why you and others should join
>> the Austin group. (check out some messages on the "Austin Off Topic
>> Discussion" reflector)
>>
>> Why do we need that?
>>
>> I'm not trying to say that it's a bad idea, but POSIX is not a
>> standard that's universally adopted, and is focused on language
>> extensions.  It's more than worth considering what the POSIX standard
>> says and does by Boost.Threads, and it would be folly for me to
>> recommend to the C++ standards committee any library that violated
>> POSIX in any way, or was counter to POSIX, or couldn't leverage
>> current or future POSIX standards. But that doesn't mean that I should
>> have a vested interest in shaping a POSIX.C++ standard.
>
> Here's an illustration. (no link this time; see c.p.t. for details)
>
> <quote>
>
>> Ok, ok. I agree that a strictly confirming *application* should rely
>> on guaranteed thread termination and always-unwinding. Perhaps we have
>> a "scope" problem here, again. All I want is that a strictly
>> conforming *function* shall not rely on unwinding IF it can be invoked
>> within a C++ scope/functions that could restrict propagation and
>> unwinding using exception specifications. There just ought to be some
>> loophole/hint for that, don't you think so?
>
> No, I don't, because none of this is even remotely within the scope of
> the  POSIX standard. POSIX deals with thread cleanup handlers, which are
> called  before the thread terminates. Period. There's no finalization;
> there's no  chance of process termination. It is completely irrelevant
> to "strictly  conforming" POSIX implementations or applications what
> might happen if it  were, hypothetically, possible for an "unhandled"
> "exception" to terminate  the process, because neither "unhandled" nor
> "exception" are meaningful  concepts.
>
> IF there were a "C++ binding to POSIX", and IF that binding said that
> the  mechanism for POSIX cleanup was actually "C++" exception
> propagation, this  would need to be covered. But that hasn't happened
> and very likely won't  happen.
>
> </quote>

The motivations are backwards here, though.  If the C++ language adopts a
threading library, POSIX systems will have a lot of motivation for
defining a POSIX C++ binding, or at the very least, making a particular
implementation's POSIX binding compatible with the C++ threading.

>From my perspective (and I would assume the perspective of the C++
committee), what's important is that anything I do in Boost.Threads needs
to be compatible with POSIX (as well as other threading systems), but
that's really it.  I don't have any vested interest in extending POSIX for
any reason.  So, I'm intested in what's going on, but I'm not a good
candidate for helping champion any proposals you're making for POSIX.

-- 
William E. Kempf