Boost logo

Threads-Devel :

From: Roland Schwarz (roland.schwarz_at_[hidden])
Date: 2006-04-10 19:01:58


I have just uploaded my first attempt to reorganize the threading code
into platform dependent sections, to the vault.

Anthony, Matt, Please have a view on this before I will check anything
into the CVS, since I need to reorganize the directory structure a bit.
  I'd like to reach consensus on this before, because it is not easy to
delete directories from CVS again once created.

You just can grab the boost_threadpp.tar.gz file and extract it onto
your regular boost tree. It will not overwrite anything, since the new
parts live in:
boost/threadpp
and
libs/threadpp
side by side to the current library. I am not sure if I should change
the name back to thread again before going into the CVS. Your thoughts?

The platform split is made of two parts:

1) a include dispatcher macro within detail/platform.hpp which
dispatches from user interface include files e.g. thread.hpp to
win32/thread.hpp

2) a Jamfile which is able to build sources in a platform (and toolset)
dependent way. (I am making use of the <build>no prerequisite.)
Currently there is only a v1 file available, v2 to follow soon.

It is also possible to have some shared code, although I currently split
everything.

The build is always attempting to compile for the pthreads interface
where available (also on windows). Platforms known not to support
pthreads can be (and should be) deactivated in the Jamfile, so no
spurious errors are emitted.
This library is named boost_threadpp_pthread.
(This is the default on unix*.)

Then the Boost.build attempts a native build on platforms where native
code is available. Currently this is true only for windows. Al tough I
am not sure if it will make sense to create a native lib on linux too,
this would be possible. (As well as for any other platforms.)
On windows this library is named boost_threadpp_win32.

The users later can decide at link time of his application which variant
to use, i.e. pthread or native.

I rearranged enough of the code to demonstrate the principle, i.e.
condition, mutex and thread.

What I know is missing:
autolinking,
tss,
barrier,
rwmutex,
Jamfile.v2,
tests,
dynamic linking

Also please note that I have not yet tried to link any userland code to
the built libraries. I have tested however that the install command of
bjam copies everything to the expected places, i.e. headers and all
library variants.

Please let me know what you think about this setup, so I can adapt it
further before going to CVS and writing more detailed developer
documentation to the wiki.

Regards,

Roland


Threads-Devel list run by bdawes at acm.org, david.abrahams at rcn.com, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk