RE: [boost] Re: Re: Threads & Exceptions

From: Moore, Dave (dmoore_at_[hidden])
Date: 2002-08-05 13:31:29

Eric Woodruff:

Personally, I don't think advanced_thread should compose a boost::thread or
derive from it. boost::thread is fairly impotent. If the advanced_thread was
named asyncronous_function_adapter, boost::thread would be depreciated, as I
said earlier. (Of course, for the platform neutrality,
asyncronous_function_adapter would have to dervive from a protected private
base class where the platform-specific code would reside.)

However, removing the non-templated (publically accessible) base type would
probably introduce complexity in the thread pool (which would again need to
be renamed if the thread was thrown out). I suggest instead putting
boost::thread in a sub namespace and frowning at its use.

**Reply**

Yes, but there are of course many ways to use threads in application designs
besides asynchronous function calls.  Asynch function calls are a useful
mechanism, but aren't a universal replacement for  a general purpose
threading class.

boost::thread may or may not be "impotent" now, but a future version will
hopefully include cross-platform cancellation, and thread attributes like
priority, stack size, etc.  These features are crucial for folks porting
existing pthreads and win32 threaded apps over.  I'm not sure pushing
boost::thread down into a sub namespace would serve those porting existing
threaded applications that currently operate on threads at the the
create/join()/cancel() level.

There is some good reading in this mailing list's archives on the rationale
for this "bottom up" approach.

In other words, there's room for both levels of thinking about threading in
boost::threads.  An async-adapter built on top of boost::threads can "grow"
in functionality as boost::threads grows, adding cancellability, etc.

Regards,
Dave