[boost.thread] Experimental alternative TLS implementation
While searching for a method to overcome the intentional memory leak on the windows implementation of tss, I wrote a new shrink wrapped version of tss, for discussion of possible improvements over the current implementation. The proposal will not alter the current interface, but adds the following features: * Completely orthogonal to boost::thread * No memory leaks * Twice as fast for -> operator * Threads may (in principle) live after end of main() Currently this will only work on windows, but it should be possible to port it to pthreads as well with little effort. I have uploaded the file tls_win.zip to the boost filearea on Yahoo. Roland
I am wondering why my post seemingly slipped through. Is it because it is completely OT? Is it because everyone is busy with 1.32 rollout? Is it because of holidays? Or are my suggestions simply not wortwhile to be discussed? Has this already been discussed? If so I would kindly ask someone to point me to the relevant thread since I was not successful in finding something appropriate. Still in the hope to get some feedback. Roland
Roland wrote:
I am wondering why my post seemingly slipped through.
Is it because it is completely OT? Is it because everyone is busy with 1.32 rollout? Is it because of holidays?
In my case, it's because I'm still catching up from being on vacation most of last week.
Or are my suggestions simply not wortwhile to be discussed? Has this already been discussed? If so I would kindly ask someone to point me to the relevant thread since I was not successful in finding something appropriate.
Still in the hope to get some feedback.
I hope to get time fairly soon. My first priority, though is the regression errors that appeared for statically linked Boost.Threads while I was gone. Any ideas? Mike
On Wed, 18 Aug 2004 13:59:18 -0400 Michael Glassford <glassfordm@hotmail.com> wrote:
... My first priority, though is the regression errors that appeared for statically linked Boost.Threads while I was gone. Any ideas?
I tried to look into this, but I am not able to acces http://www.boost.org/regression-logs/developer it gives me a 404 - FIle not found. So I cannot even see what is failing. Did I miss something? Roland
Roland wrote:
On Wed, 18 Aug 2004 13:59:18 -0400 Michael Glassford <glassfordm@hotmail.com> wrote:
... My first priority, though is the regression errors that appeared for statically linked Boost.Threads while I was gone. Any ideas?
I tried to look into this, but I am not able to acces
http://www.boost.org/regression-logs/developer
it gives me a 404 - FIle not found. So I cannot even see what is failing. Did I miss something?
The regression-logs dir disappeared some time ago, and not all parts of it have been restored. You can go to what the original redirect there took you to for now: http://meta-comm.com/engineering/boost-regression/developer/ -- -- Grafik - Don't Assume Anything -- Redshift Software, Inc. - http://redshift-software.com -- rrivera/acm.org - grafik/redshift-software.com - 102708583/icq
On Wed, 18 Aug 2004 13:59:18 -0400 Michael Glassford <glassfordm@hotmail.com> wrote:
I hope to get time fairly soon. My first priority, though is the regression errors that appeared for statically linked Boost.Threads while I was gone. Any ideas?
Can you give me any specific pointers? E.g I found http://tinyurl.com/48a5t Is this a typical error you are talking about? What are those xlock and xmutex files? They seemingly try to pull in the single threaded lib somehow. Roland
Yes, that's typical of the error I was talking about. Bronek Kozicki says he has tracked down the problem for me: adding "<threading>multi" to boost_thread_lib_base and boost_thread_dll_base in libs\boost\thread\build\jamfile fixes the problem. I haven't been able to verify this because I don't have the problem on my machine, but as it appears related to a problem that I have seen and previously worked around, I believe he is correct and have committed the change to cvs. Some questions for bjam gurus: 1) This appears to be a bjam bug, since that option already appears in a template that is being used by both boost_thread_lib_base and boost_thread_dll_base. This appears to be the same bug as or related to one I previously reported (there's another option that's also in the template that isn't being picked up). Will this be fixed soon? 2) Why is this bug only appearing now on the machines running regression tests, and not before? 3) Why is the bug still not appearing on my machine? (I generally update and rebuild bjam whenever I get new source). Mike "Roland" <roland.schwarz@chello.at> wrote in message news:20040819162809.YFWZ11286.viefep13-int.chello.at@speedsnail...
On Wed, 18 Aug 2004 13:59:18 -0400 Michael Glassford <glassfordm@hotmail.com> wrote:
I hope to get time fairly soon. My first priority, though is the regression errors that appeared for statically linked Boost.Threads while I was gone. Any ideas?
Can you give me any specific pointers?
E.g I found http://tinyurl.com/48a5t Is this a typical error you are talking about? What are those xlock and xmutex files? They seemingly try to pull in the single threaded lib somehow.
Roland
_______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
On Thu, 19 Aug 2004 13:12:31 -0400 Michael Glassford <glassfordm@hotmail.com> wrote:
Yes, that's typical of the error I was talking about.
Bronek Kozicki says he has tracked down the problem for me: adding "<threading>multi" to boost_thread_lib_base and boost_thread_dll_base in libs\boost\thread\build\jamfile fixes the problem.
Fine to hear! Since I am still in the stage of learning to understand bjam the following observation might be of no significance, but who knows.... In the file: boost\bin\boost\libs\thread\test\test_thread_lib.test\vc7.1\debug\runtime-link-static\threading-multi\test_thread_lib.CMD which obviously specifies the linker input I found somethin strange: "..\..\..\bin\boost\libs\thread\test\test_thread_lib.test\vc7.1\debug\runtime-link-static\threading-multi\test_thread.obj" "..\..\..\bin\boost\libs\thread\test\test_thread_lib.test\vc7.1\debug\runtime-link-static\threading-multi\tss_null.obj" "..\..\..\bin\boost\libs\thread\build\libboost_thread.lib\vc7.1\debug\runtime-link-static\threading-multi\libboost_thread-vc71-mt-sgd-1_32.lib" "..\..\..\bin\boost\libs\test\build\libboost_unit_test_framework.lib\vc7.1\debug\runtime-link-static\libboost_unit_test_framework.lib" While the first three lines refer to \runtime-link-static\threading-multi\ the fourth refers only to \runtime-link-static\ Does this explain where the single threaded CRT gets pulled in? BTW.: This is the same as in MSVC6 altough the linker does not complain in that case. Roland
Roland" <roland.schwarz@chello.at> wrote in message news:20040819174042.JRPY6650.viefep17-int.chello.at@speedsnail...
On Thu, 19 Aug 2004 13:12:31 -0400 Michael Glassford <glassfordm@hotmail.com> wrote:
[snip]
In the file:
boost\bin\boost\libs\thread\test\test_thread_lib.test\vc7.1\debug\runt ime-link-static\threading-multi\test_thread_lib.CMD
which obviously specifies the linker input I found somethin strange:
"..\..\..\bin\boost\libs\thread\test\test_thread_lib.test\vc7.1\debug\ runtime-link-static\threading-multi\test_thread.obj"
"..\..\..\bin\boost\libs\thread\test\test_thread_lib.test\vc7.1\debug\ runtime-link-static\threading-multi\tss_null.obj"
"..\..\..\bin\boost\libs\thread\build\libboost_thread.lib\vc7.1\debug\ runtime-link-static\threading-multi\libboost_thread-vc71-mt-sgd-1_32.l ib"
"..\..\..\bin\boost\libs\test\build\libboost_unit_test_framework.lib\v c7.1\debug\runtime-link-static\libboost_unit_test_framework.lib"
While the first three lines refer to \runtime-link-static\threading-multi\ the fourth refers only to \runtime-link-static\
Does this explain where the single threaded CRT gets pulled in?
I expect so. Hopefully that's what Bronek's change fixes. Mike
Michael Glassford wrote:
Bronek Kozicki says he has tracked down the problem for me: adding "<threading>multi" to boost_thread_lib_base and boost_thread_dll_base in libs\boost\thread\build\jamfile fixes the problem. I haven't been
I think I wrote about libs\boost\thread\test\Jamfile , not about libs\boost\thread\bjam\Jamfile . One have to append <threading>multi in template boost_thread_test_lib, just below : ## default build ## (see attached patch). The same line can be appended to template boost_thread_test_dll, but I did not put it in patch (this time). I do not know why it works, I do not even know how to write Bjam files, but it does work - all tests passed fine. The point is that it has to be added in this place - modyfing libs/thread/build/Jamfile or adding "<threading>multi" line somewhere above ": ## default build ##" does not fix the problem - bjam will still use single-threaded unit test framework, then two different versions of statically linked CRT (single-threaded from test unit framework and multi-threaded from test units) are linked to single executable and we have linker errors. Maybe source of problem is not in the threads library, but in its test unit or bjam (or both)?s B. PS. I'm using "Boost.Jam Version 3.1.10. OS=NT." Index: boost/libs/thread/test/Jamfile =================================================================== RCS file: /cvsroot/boost/boost/libs/thread/test/Jamfile,v retrieving revision 1.29 diff -u -r1.29 Jamfile --- boost/libs/thread/test/Jamfile 9 Aug 2004 21:41:29 -0000 1.29 +++ boost/libs/thread/test/Jamfile 19 Aug 2004 18:28:37 -0000 @@ -40,6 +40,7 @@ <define>BOOST_THREAD_TEST=1 <runtime-link>static : ## default build ## + <threading>multi ; template boost_thread_test_dll
"Bronek Kozicki" <brok@rubikon.pl> wrote in message news:4124F942.8030302@rubikon.pl...
Michael Glassford wrote:
Bronek Kozicki says he has tracked down the problem for me: adding "<threading>multi" to boost_thread_lib_base and boost_thread_dll_base in libs\boost\thread\build\jamfile fixes the problem. I haven't been
I think I wrote about libs\boost\thread\test\Jamfile , not about libs\boost\thread\bjam\Jamfile .
Sorry, my mistake.
One have to append <threading>multi in template boost_thread_test_lib, just below : ## default build ## (see attached patch). The same line can be appended to template boost_thread_test_dll, but I did not put it in patch (this time).
Actually, it was in the patch you sent me and I included it in my commit.
I do not know why it works, I do not even know how to write Bjam files, but it does work - all tests passed fine. The point is that it has to be added in this place - modyfing libs/thread/build/Jamfile or adding "<threading>multi" line somewhere above ": ## default build ##" does not fix the problem - bjam will still use single-threaded unit test framework, then two different versions of statically linked CRT (single-threaded from test unit framework and multi-threaded from test units) are linked to single executable and we have linker errors. Maybe source of problem is not in the threads library, but in its test unit or bjam (or both)?s
I've fixed it in the right place now, I hope.
B.
PS. I'm using "Boost.Jam Version 3.1.10. OS=NT."
Mike
participants (2)
-
Bronek Kozicki -
Michael Glassford -
Rene Rivera -
Roland