From: Dale Peakall (dale.peakall_at_[hidden])
Date: 2002-08-12 11:46:43
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.
> > > I think that the "low level library that allows users to do the work"
> > > argument must not be overused. If I want a low-level library, I will
> > > use pthreads.
> > You appreciate that using pthreads denies you a large number of
> > advantages that can be derived from using boost.threads: Cross-platform
> > interoperability, exception safety, a C++ style interface etc.
> Pthreads is a standard and is cross-platform. Exception safety? True, but I
> can use the Boost synchronization primitives without using boost::thread
> (if they work for me; a pthread_mutex is much less safe but it is more
pthreads is cross-platform which is why we have three different
implementations of Boost.Threads at present - only one of which is based on
> 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.
C++ provides a number of features that aren't available in C, that affect how
you can do things. e.g. templates.
> > Boost.Threads is a low-level library, but it's a low-level *C++* library,
> > that solves a large number of *C++* problems.
> See above. A good design is a good design, with or without the emphasized
> C++. If you have specific points, I'll be interested to hear them.
If we were happy with the pthreads interface, why have we gone to all the
effort of producing Boost.Threads?
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk