Boost logo

Boost :

From: Eric Woodruff (Eric.Woodruff_at_[hidden])
Date: 2002-08-05 13:14:32


Here's how to provide platform neutrality while keeping typesafety and avoiding #ifdef:

I will fabricate an example loosely based on boost::thread.

// thread.hpp

namespace boost {

    class thread {
        public:
            //...
        private:
            void runAsynchronousMethod () {
                // run our happy boost::function
                // deal with exceptions
            }

            boost::shared_ptr<class PlatformSpecificThread> psThread; // must be last attribute to make sure "this" is fully constructed before thread starts.
            friend class PlatformSpecificThread;
    };
}

// thread.cpp - win32 version in an isolated subdirectory

#include <boost/thread.hpp>
#include <windows.h>

using boost::thread;

class PlatformSpecificThread { // everything private!
    PlatformSpecificThread (boost::thread* const thread)
        : handle (CreateThread (0, 0, &run), reinterpret_cast<void*> (thread), 0, 0)) {
    }

    ~PlatformSpecificThread () {
        CloseHandle (handle);
    }

    static DWORD WINAPI run (void* typelessPointer) { //nothrow
        if (0 == typelessPointer) return FALSE;

        reinterpret_cast<boost::thread*> (typelessPointer)->runAsynchronousMethod (); // can be implemented in the header because it's platform neutral :)
        return TRUE;
    }
        
    HANDLE handle;
    friend class boost::thread;
    // needs to be a friend of checked_delete as well for use with shared_ptr
}

thread::thread (/*boost::function*/)
    : psThread (new PlatformSpecificThread (this)) {
}

// thread specific methods like thread::join, etc, only the few platform specific methods are necessary here

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



Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk