[boost] Re: Re: Threads & Exceptions

From: Eric Woodruff (Eric.Woodruff_at_[hidden])
Date: 2002-08-05 12:49:17

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 ----- 
  From: Moore, Dave 
  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