RE: [boost] Re: Thread Lib and DLL

From: Steven Mauceri (sm_at_[hidden])
Date: 2003-03-29 13:57:33

Yes, cleanup could be solved this way (or with other approaches, daemon
thread, periodic timers, etc).  However, I don't see cleanup as the core
issue with making TLS work without a DLL under Win-32.

Currently, boost.threads supports (uses/specifies) the POSIX style
cleanup model where the cleanup function is called on the thread that is
closing.  This cleanup function can also set/get/clear TLS values (which
should continue to be valid for the "closing" thread until it exits
[read: right after the cleanup func finishes]).

Boost.threads TLS/DLL approach is used to fire off the cleanup function
on the closing thread.

There are also issues with this [DllMain single-dispatch rules, someone
waiting in a cleanup handler, and others], but this approach at least
allows boost.threads under Win32 to conform to it's own specification.

[ Note: Windows internally seems to have been fixed by MS at some point
to dispatch DLL_THREAD_DETACH in a "reverse-dependency" order, which
makes sure that the DLL that was most recently loaded is the first to
receive DLL_THREAD_DETATCH messages.  Without this behavior, DLL TLS
support would have serious issues in even working out of the box.  The
reason this seems to be a fix by MS at some point, is that the
DLL_THREAD_ATTACH order is *NOT* in dependency order, but in what
appears to be link order.  Perhaps someone from MS can comment on the
implementation, and how it came to follow these [undocumented] rules. ]

For boost.threads stand-alone lib, the only solution I currently see is:

- Relaxation of the cleanup function handler requirement from "WILL BE
CALLED", to "MAY BE CALLED" from the closing thread.

If this was done, then Unix implementations would continue working as is
(call from cleanup func in closing thread), and windows implementation
would have a worker thread(s) dispatch the cleanup handler functions
when threads were shutdown (this thread would wait on the thread object
when TLS values were in use on a particular thread).

Note, the calls to the win32 boost TLS functions can be made to "work"
correctly if dispatched from a cleanup-handler, which is what we want.
However, OS level functions, [GetCurrentThread() and friends] would
yield the thread of the "cleanup dispatcher" thread which is indeed
incorrect.

Since *few* people do "fancy" things in TLS [usually they
deallocate/free resources], and *even less* people call other TLS
functions from cleanup handlers, and *even less* people call OS-thread
functions inside their TLS cleanup handlers, I see the change in the
specifications to be reasonable.

With something like this I see a valid (if complex in implementation)
way to support boost.threads as a static lib.

Willam Kempf has be gracious enough to discuss many of the issues at
length with me and has examined various approaches to solving the TLS /
DLL dependency issues.  At first I thought it should be possible to
solve, but I now feel that solving it within the scope of the current
TLS-cleanup handler specification is impossible without modifying the
specification (from WILL to MAY "call from the closing thread").

Here Bill and I disagree :-).

Bill feels that the specification should not be changed, since this is
an OS-brokenness issue that can be corrected by MS at some point in the
future.

I feel, that the boost thread specification should be modified for this
(very rare) corner case, in order to support Win-32 static lib builds of
boost.threads.

I don't see any right or wrong here, as it is fundamentally a matter of
specification.

- Steve

PS
I also share Bill's desire to find a workable solution to this problem.
However, I am pessimistic that there exist solutions that work under
Win-32 and conform to the boost thread TLS spec rules for cleanup
handlers.

-----Original Message-----
From: David Abrahams
Sent: Saturday, March 29, 2003 10:16 AM

> I don't really understand the issues here, but I was
> wondering if you could reclaim "leaked" TLS resources
> lazily somehow, by looking for unused TLS the next time
> new TLS is requested.  Just a thought...

-- 
Dave Abrahams
Boost Consulting
www.boost-consulting.com
_______________________________________________
Unsubscribe & other changes:
http://lists.boost.org/mailman/listinfo.cgi/boost