--- Douglas Gregor <[EMAIL PROTECTED]> wrote:
> The Boost.Threads library defines its own threading
> model and implements it
> on several platforms. If two distinct threading
> models are useful with the
> Boost.Threads model, then it can be extended to
> support that model. Windows'
> two threading models aren't the only threading
> models out there, and one
> thing that Boost.Threads brings to the table is a
> threading model that is
> consistent across all platforms. How portable would
> a program that relies on
> two coexisting Win32 threading models be?
Well, how can I use boost::threads with my toy
operating system? Would it be possible to implement
the boost::threads core based on ImplTraits or polices
that users can customize? If so, then we could add
build options to use a set of wrappers for widely used
OS's. This way we'll solve all the compile time and
code size issues for "officially" supported platforms
and let users to scale/customize the core thread
functionality at the same time.
Everybody is happy!
Here is a simple example on how it could be done:
// ============
// thread_core.h
template <typename ImplTraits>
class thread_core
{
...
};
//end of thread_core.h
//=====================
// ============
//thread.h
#if defined WINDOWS
#define TRAITS WinThreadTraits
#elif defined VMS
#define TRAITS VmsThreadTraits
#elif defined OS2
#define TRAITS OS2ThreadTraits
#endif
template <typename ImplTraits> class thread;
//wrapper for the 'thread' class
class thread
{
public:
thread<TRAITS> *m_pImpl;
};
//end of thread.h
//=============
//==============
//thread.cpp
#include "thread_core.h"
#include "thread.h"
//implement all the standard traits
//and the 'thread' wrapper functions
#if defined WINDOWS
struct WinThreadTraits
{
...
};
#elif defined VMS
struct VmsThreadTraits
{
...
};
#elif defined OS2
struct OS2ThreadTraits
{
};
#endif
thead::thread() : m_pImpl = new thread_core<TRAITS>();
{
}
...
//end of thread.cpp
//==================
In this sample thread_core.h has a complete code for
the thread_core class that can be scaled/customized by
using different traits. I could use it for my toy OS
directly.
The thread.h can be used for "official" platforms
only. It is just a thread_core wrapper.
thread.h doesn't include thread_core.h so there are
not any compilation time/code size issues.
The thread.cpp implements the "official" thread_core
wrappers.
thread.cpp can be build as a DLL/.lib for a specific
platform.
> I'm not opposed to providing an option to include
> all code into headers
> (e.g., a BOOST_SIGNALS_NO_LIB macro akin to the
> RegEx macro), and clearly
> where there are cases with problems stemming from
> the DLL/user code split
> (e.g., pointers allocated in the DLL and freed in
> user code)
BOOST_SIGNALS_NO_LIB would work just fine for me.
I agree with everything you said on the economics
issues. Fortunately there is a solution that can make
everybody happy. I'd suggest to consider the
architecture that I proposed above for both
boost::threads and boost::signals libraries.
> I'll fix the
> library, but I don't expect to see Boost moving
> toward putting more code
> into headers in the future.
IMHO we'll regret it later.
Eugene
__________________________________
Do you Yahoo!?
Yahoo! SiteBuilder - Free, easy-to-use web site design software
http://sitebuilder.yahoo.com
_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
