Re: Boost.Threads - name of the "thread" type

From: williamkempf_at_[hidden]
Date: 2001-06-22 13:22:41

--- In boost_at_y..., John Max Skaller <skaller_at_o...> wrote:
> williamkempf_at_h... wrote:
> 
> > >       If you don't, people will have to roll their own.
> > 
> > Which is a safer approach.  
> > Seriously.  This may sound backwards, 
> 
> 	It doesn't sound backwards. You're probably right.
> The arguments you present suggest that there would be no
> consensus on the ISO WG if cancellation were part of the 
> library. It is OK (IMHO) to have a restricted set of thread
> handling facilities that will make it easier to solve
> a reasonable class of problems, while still requiring
> more sophisticated systems to roll their own.
> 
> > Some of the issues:
> > 
> > 1)  Cancellation usually doesn't address lifetime issues 
completely
> > or appropriately.  For instance, pthread cancellation and Win 
thread
> > cancellation when used in the C++ language fails to properly call
> > destructors.  
> 
> 	This is an issue which needs to be addressed by the
> Standardisation committee. But first, the abstract machine
> needs to be extended to support the notion of threads. :-)

Which is something that can be done when the C++ standards committee 
chooses to adopt a threads concept, and we do hope that the Boost 
effort is considered at that time.  However, the Boost effort can't 
address this, because we can't change the abstract machine (at least 
not easily or portably).  That's why I've said that cancellation 
*may* be considered.  It is a feature that most people are going to 
want... and that despite the fact that historical evidence shows it 
to be dangerous even when it's a part of the language.  But because 
of the dangers and the complexity, I'm not going to make it a feature 
of Boost.Threads any time in the near future.

> 	This is also necessary before any threads library
> (even a simple one) can be accepted as a part of the Standard 
library.
> Indeed, if the only consequence of proposing a boost::threads 
library
> is that the abstract machine is modified to support thread concepts,
> the library will have been very useful.
> 
> 	I'll add:
> 
> 	Posix cancellation points are deficient, there are a couple
> of socket calls which block, but which are not cancellation points.
> 
> > A language solution instead of a library solution can eliminate 
most,
> > but not all of these problems.  Again, look at Java for proof of 
this.
> 
> 	[Best not to start me off on a rant :-]

Hey, I dislike Java as much as the next guy, but Java has shown many 
of the dangers in a poor thread design that every language/library 
should pay attention to.  Cancellation is a big one.  I'm not sure 
that a safe form of cancellation can be done, despite how easy it is 
to add cancellation explicitly to thread routines.
 
> > Explicit user cancellation coded with condition variables are 
trivial
> > to implement, and are fully safe, however.
> 
> 	Provided all blocking system calls are wrapped with checks
> on the condition variables. So you must use the wrapper code
> exclusively  (can't use C calls). Probably, this is acceptable.

You're bringing up another issue here that's pertinent to only a 
portion of designs that need cancellation.  For realtime systems that 
need immediate cancellation (i.e. they can't wait until after a 
return from a blocking routine) a wrapper is going to be problematic 
and a library supplied cancellation mechanism is likely going to be a 
necessity.  However, experience shows this need to be in the 
minority, so weighing the pros and cons leaves me still wanting to 
ignore cancellation.

Bill Kempf