Re: [boost] Attempting resolution of Threads & Exceptions Issue

From: Peter Dimov (pdimov_at_[hidden])
Date: 2002-08-12 12:24:44

From: "Dale Peakall" <dale.peakall_at_[hidden]>
> On Monday 12 August 2002 5:03 pm, you wrote:
> > From: "Dale Peakall" <dale.peakall_at_[hidden]>
> >
> > > > > Have the default beviour be for threads to terminate on uncaught
> > > > > exceptions.
> > > >
> > > > This is common between 1/2 & 3. What 3 calls a "thread" 1 calls
> > > > "thread<void>" and the behavior is as specified above.
> > >
> > > Only for thread<void>.
> >
> > Most definitely, since thread<R> where R != void produces an interface
> > where join() returns a value, and this is not covered by (3).
>
> 3 can still return a value.

Yes, I have probably misunderstood what you mean by (3).

There are two very good arguments for (3) (exceptions from thread function
objects cause std::terminate.) First, this is the most consistent behavior
for the main thread. Second, having threads _not_ terminate the process on
exceptions can (and reportedly does) lead to bugs that remain undetected.

But please note that these arguments have much less weight when applied to
threads that return a value.

> pthreads is cross-platform which is why we have three different
> implementations of Boost.Threads at present - only one of which is based
on
> pthreads.

I know you know about pthreads-win32.

> > C++ style interface? If the interface is well designed, it doesn't need
> > "C++" or "OO" labels.
>
> I'm going to list a couple of points below, I know you know them, but how
> else am I to argue my corner.
>
> The target language partly defines the requirements.  Most C libraries
have
> problems with exception-safety in C++, because the concept doesn't exist
in C.

Yes. "Exception safe" is most definitely a trait that a good design should
have.

> C++ provides a number of features that aren't available in C, that affect
how
> you can do things.  e.g. templates.

Yes. C++ has greater expressive power, which means that you _can_ create a
better design. This doesn't mean that any "C++ style" design is a better
design.

But we digress. My point was that Boost.Threads should provide significant
added value over pthreads.

I said that we shouldn't _overuse_ the "low level library" argument. Library
design is a delicate balance; deciding what should be included and what is
to be left out is difficult (probably the most difficult part.)

It is best to look at things from users' perspective. True, feature X is
easily built on top of the core subset Y. But if a significant group of
users will need to reinvent X because it is needed to solve their problems,
then it is our responsibility as library designers to include X.

Examples of X?

* a thread that returns a value (including exceptional returns);
* a thread-safe join() where a second join() is a no-op;
* a way to obtain a full-featured "handle" to the current thread;
* a way to put threads in standard library containers;
* a thread identifier usable as a std::map key;
* a way to solve the initialization order problem in the presence of
threads.

> If we were happy with the pthreads interface, why have we gone to all the
> effort of producing Boost.Threads?

In order to produce a better interface? In order to better address users'
problems? Or in order to create yet another "low level" API?