Date: 2001-08-23 20:31:27
--- In boost_at_y..., "Peter Dimov" <pdimov_at_m...> wrote:
> Another question:
> How do I create a 'joinable' thread object representing the main
You can't. And my first thought was "trying to join the main thread
sounds like a major design flaw". That aside, once I thought this
one through (which is why I didn't respond sooner) I realize that the
real problem you have here is with thread adoption semantics.
This is a similar problem to what I encountered when trying to design
semantics that allowed multiple "joins". POSIX simply doesn't
support this. The best you can do is allow for multiple "waits".
What's the difference? A "join" gaurantees that the thread has fully
completed, including the running of cleanup handlers and the
recycling of the "thread id", while a "wait" only gaurantees that the
thread is done running it's thread entry procedure. I honestly don't
think you can get POSIX (or the proposed Boost.Threads semantics) to
allow for multiple "joins" given the need to adopt threads. You
simply can't tell if the thread has already been joined, nor can you
insure that the creator won't attempt to do a "native join".
That said, supporting multiple "waits" is trivial for both POSIX and
the proposed Boost.Threads semantics. You simply create a monitor
(mutex and condition variable) stored in TLS and ref-counted. The
TLS cleanup routine is used to notify all threads waiting on the
This will _usually_ be enough. The only thread that absolutely has
to "join" instead of "wait" is the "last" thread, in order to insure
that all cleanup occurs before the process ends.
The bigger issue for you with the proposed Boost.Threads semantics is
that the thread object created through the default constructor is
valid only within that thread. I can lift that restriction... I
added it only to simplify the Win32 implementation so that I didn't
have to call DuplicateHandle(). In other words it was an
optimization. I expected someone to ask about it, but no one did :).
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk