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.
----- Original Message -----
Newsgroups:
gmane.comp.lib.boost.devel
Sent: Monday, 2002:August:05 12:59
PM
Subject: RE: Re: Threads &
Exceptions
> 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
_______________________________________________
Unsubscribe
& other changes: http://lists.boost.org/mailman/listinfo.cgi/boost