Re: [boost] Re: Re: the boost::signal sample crashes

From: E. Gladyshev (egladysh_at_[hidden])
Date: 2003-08-05 02:48:55

--- Douglas Gregor <gregod_at_[hidden]> 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