RE: [boost] Re: Threads & Exceptions

From: Moore, Dave (dmoore_at_[hidden])
Date: 2002-08-05 11:59:46

> My complaints on the ifdefs were on the underside of the thread. C++ alone
provides plenty of 
> mechanisms for mapping the common interface to different platforms, with
typesafety (instead of 
> the reinterpret_casts<>!)--again, the topic of a different discussion, at
which point it would be 
> easier just to submit a replacement as example.

Fair enough, but it's a hard problem to solve w/o resorting to (1)
#including os-specific files like <windows.h> in the interface which wreak
havoc on namespaces, macros, etc., or (2) having a complete shadow set of
dynamically allocated Pimpl classes.  It's always interesting to see
alternative approaches, though.

> There is no reason to make users of thread handle their own exceptions
because there is only one 
> mechanism to do it, and every user will have to repeat this code in their
implementation.  
> in thread processes have always been ambiguous to me, it seems that no
framework out there 
> supportws them properly and just expects them to be caught and sometimes
ignored.

> If you'll take note of the advanced_thread usage, it not provides a
generic way to run any   
> boost::function asynchronously, get its return value and deal with
exceptions it may throw--a 
>complete solution and something currently not yet available. Of course one
could take the 
>perspective that advanced_thread is really an asynchronous function
adapter, but that deprecates the >need to support what is currently offered
by boost::thread--which is why I suggested a possible 
>replacement.

I agree with your statements about reuse and flexibitly for asynchronous
function calls and flexibility in handling exceptions.  I'm just not sure
that an inheritance from (or replacement of) boost:thread is the best
solution.

Consider an alternative: a thread_pool object which can enqueue
boost::function calls and distribute them to a managed pool of threads ready
to execute them.  boost::function gives you the hook to implement -any-
scenario of argument passing, return value capture, and exception handling
you wish.  This is a problem (IMHO) that suggests a solution via composition
of two existing classes, not inheritance.

See:
http://groups.yahoo.com/group/boost/files/thread_pool.zip 

For a draft of a solution which may (hopefully) find its way into
Boost.Threads.

Regards,
Dave