Date: 2001-06-08 09:51:04
--- In boost_at_y..., <boost_at_y...> wrote:
> This email message is a notification to let you know that
> a file has been uploaded to the Files area of the boost
> File : /threads/threads2.zip
> Uploaded by : williamkempf_at_h...
> Description : Initial Phase II impelemtation.
> You can access this file at the URL
> To learn more about file sharing for your group, please visit
Changes to Phase I code:
* Removed the "pimpl" idiom that concerned so many. I took the
approach MS took with _beginthread to not require an inclusion of the
Windows.h system header (which results in many bad macros being
defined), namely using "unsigned long" for HANDLE types and casting
them in the implementation. This is non-portable and may cause
problems in a hypothetical future version of Win32, but I'd rather
address that later than poison the namespace with MS symbols now.
Phase II additions:
* Added a tss class for thread specific storage.
* Removed the boost::detail methods used by tests and examples for
thread creation and control.
* Added a thread class for thread creation and control. This class
currently defines a "minimum" of the requirements I feel necessary
The code right now has been only minimally tested under Win32. I've
written the necessary pthreads code, but I've not even compiled
this. Please, no comments at this point about the implementation.
We need to focus on the interface and the functionality.
The thread class in particular needs very careful scrutiny. There
are several tricky issues that need to be considered and accounted
for in the interface for a full thread concept. I'll list the main
ones that I can think of:
* There should probably be some way to control the stack size of
created threads. However, even the pthreads standard does not
require this functionality and when present it's hard to use this
functionality portably. The stack requirements for each system are
just going to vary too much.
* There should also be a way to control a threads priority. This too
will be difficult to handle portably.
* We need to figure out how we'll handle "adoption" of threads
created outside of the Boost.Threads library. For example, if we
have clean up stacks (see below) and a method calls thread::self() to
add something to the stack, but the method is running under a thread
created outside of Boost.Threads (a fairly likely thing) then there
will need to be a way to "adopt" this thread under the Boost.Threads
* Clean up stacks need to be considered. These are similar to atexit
() in that they register routines to be run when the thread exits.
This concept will help with memory management of tss objects, for
instance. The problem is, not all systems support clean up stacks
(the Win32 system is one) and adding the concept on those systems
will be problematic, especially for "adopted" threads.
* We need to figure out how to deal with cancellation of threads. I
personally don't think that Boost.Threads should even support
cancellation since it causes problems with stack unwinding very
similar to exit() in the C++ standard (but since threads are created
and destroyed while the process continues to run this problem is
worse for threads). If we don't support cancellation, however, we
still have to address this issue when it comes to "adopted" threads
and with regard to legacy code or processes.
* Currently all threads created are registered in Boost.Threads for
purposes of the thread::join_all() method. However, some systems may
allow for threads to "evaporate" when the process ends and so it may
be convenient to allow such threads to be "detached" from the
Boost.Threads system (i.e. they won't be waited on during join_all
()). This is similar to, but slightly different from, the
pthread_detach() concept. Portability is my only concern here.
* We need to consider whether a thread::exit() routine should exist.
Given the problems with stack unwinding I'd think not, but...
* We need to consider what to do about thread return codes. I've
rarely seen them put to any use. Most C thread systems use an
integer return type from threads but I question whether or not this
is really something worth having in an OO threading system.
* We also need to consider signal handling. This is a concept that's
not very portable and like cancellation it can lead to many issues in
C++ that don't exist for C. Being a Win32 programmer I'm not very
qualified to make decisions here, but this is an issue that's going
to vex the design and use of Boost.Threads.
* We may need some global "hooks" for various things, such as
creation of the system thread. For example, Win32 has a CreateThread
() method that's the lowest common denomitor for creating threads, a
_beginthread() and _beginthreadex() set of routines for use with the
C RTL which manage the creation and destruction of some TSS (TLS in
Win32 speak) data and MFC has an AfxBeginThread() routine which
manages TSS data when using MFC concepts. For truly safe thread
creation there needs to be a way to choose which of these routines is
used internally based on the applications requirements.
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk