I'm trying to switch from 1_40_0 to 1_41_0, but have run into a mysterious problem in the thread lib. My test app that I used to find the problem with thread_group::interrupt_all() failed disastrously in 1_41_0. Debugging revealed that threads were being created uninterruptable. I couldn't figure out how that was happening, though. Tracing didn't show anything setting the interruptable flags to false in the threads, but they showed up that way right after the threads started. It looks like it might be some sort of memory corruption, like a write through a bogus pointer. Adding the three 1_41_0 thread library files directly to my build (and not using the library) worked fine. Using libboost_thread and the headers from 1_40_0 worked fine as well. The failure occurred when I used the 1_41_0 headers and libboost_thread. Both the static and the dynamic libs failed in exactly the same way. The only difference between the Jamfile.v2 in each version is the removal of exceptions.cpp in 1_41_0. I don't understand the build system well enough to figure out what else might have changed. I'm building using: ./bjam address-model=32 architecture=x86 threading=multi This is with OS X 10.6.2, using gcc 4.2, building a simple command-line tool. In both cases, I built the boost libraries using address-model=32, though building with 32_64 in 1_41_0 didn't make any difference. Using 32_64 was broken in 1_40_0, so I suspect that the problem might be there. If anyone wants to take a look at this, I parked the XCode project here: http://dl.dropbox.com/u/297034/ThreadTest_41.zip, 20KB. I'm sure it can be built without the XCode project, but this may be an OS X specific problem. The project is configured to use the boost version installed in /usr/local. When run, it hits an assert right after the thread starts, showing that the thread is uninterruptable. The work-around is simply to include the three files from the library directly in the project. I have to wonder if this will happen with other boost libs as well. Any help would be greatly appreciated. - Stoney -- Stonewall Ballard stoney@sb.org http://stoney.sb.org/