Re: boost::mutex::scoped_lock conventions

From: Alexander Terekhov (yg-boost-users_at_[hidden])
Date: 2003-05-20 06:57:24

"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>

regards,
alexander.

--
"It's basically pthreads with a "we're not pthreads" attitude.."
                                    -- <http://tinyurl.com/c73l>