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

From: John Max Skaller (skaller_at_[hidden])
Date: 2001-06-22 12:58:58

williamkempf_at_[hidden] 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. :-)

        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 :-]

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

-- 
John (Max) Skaller, mailto:skaller_at_[hidden]
10/1 Toxteth Rd Glebe NSW 2037 Australia voice: 61-2-9660-0850
checkout Vyper http://Vyper.sourceforge.net
download Interscript http://Interscript.sourceforge.net