Re: New file uploaded to boost

From: williamkempf_at_[hidden]
Date: 2001-06-08 09:51:04

--- In boost_at_y..., <boost_at_y...> wrote:
> 
> Hello,
> 
> This email message is a notification to let you know that
> a file has been uploaded to the Files area of the boost 
> group.
> 
>   File        : /threads/threads2.zip 
>   Uploaded by : williamkempf_at_h... 
>   Description : Initial Phase II impelemtation. 
> 
> You can access this file at the URL
> 
> http://groups.yahoo.com/group/boost/files/threads/threads2.zip 
> 
> To learn more about file sharing for your group, please visit
> 
> http://help.yahoo.com/help/us/groups/files

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 
for Boost.Threads.

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

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

Bill Kempf