--- In Boost-Users@y..., williamkempf@h... wrote:
I've just gotten a chance to read the page. I won't comment much on the build process, but since your focus was on using Boost.Threads I'll make a few comments there.
First, you can run the regression test using Jam instead of manually running gcc. Just cd into the test directory and type your typical Jam command (hint, if you create a batch file to set your environment right the entire command can be just "Jam"). This should build the executable and run it. The benefit to this approach is that it "automagically" locates and uses the DLL. This can be helpful when debugging. However, to use the actual debugger, unless it supports JIT Debugging, you'll have to go back to manually insuring everything is set up for this (i.e. copy the DLL as you did).
Okay, I figured out how to do this, and I get the same error. When I was looking for documentation on how to use jam, there wasn't much available on the boost site. I realize that jam is not originally from boost, but a 'using jam with boost' might be an appropriate subtopic on the installation page. If nothing else, it could list possible targets. It's not a big deal, though -- I'm just moaning about lack of documentation and since I'm a developer, I know when that job usually gets done.
You asked in your paper why there needs to be a DLL.
Unfortunately,
this is the only way to clean up thread specific storage on Win32. I'm working on putting all of Boost.Threads in a DLL which will at least be more intuitive for most users.
Okay, I guess I understand this. The destructors have to run sometime. However, I think it might be a mistake to put everything in a DLL, since DLLs are inherently more complicated to get right. As it is, even though I currently can't get the DLL part to work right, I can still use boost.threads without it. I don't like thread-specific storage, so I tend to design it out.
As for the segfault... I've experienced the same problem using
gcc.
Not being a gcc user I'm finding it difficult to debug to figure out why. If you or anyone else can either give me pointers on debugging for gcc or even just supply the fix I'd be eternally grateful ;). In any event, I'm working on this one.
I actually think the segfault might be in just calling the DLL. I reduced the DLL to basically nothing (returning immediately from DLLMain), and didn't call any of the thread-specific stuff (basically test_thread.cpp without calling test_tss(), so it was still linked in), and still got the pagefault. It may simply be a gcc issue, like the -mthreads switch. I'm certainly willing to help debug. Unfortunately, my debugging efforts in c++ are currently limited to printf-style debugging. I'll get gdb going (and learn it a bit better) someday.
Bill Kempf
I also want to say that I'm not trying to put down the threads library or boost. My goal with the article was a real-life user experience that will hopefully improve future user's experiences. I like what I see of boost so far.