justin_michel said:
Platform : Windows XP, Pentium 4, Visual C++ 6 sp5
I've traced down my problem with starting a thread from a DLL called from Java JNI. If you look at the source code thread.cpp in boost, you can see that a condition variable is used block the creating thread until the new thread function is started. Basically, what I am seeing is that if you wait on this condition variable, then the thread will never start. If I remove the call to param.wait() at the bottom of the constructor then everything works fine. I can't think of a logical explanation, but it's very repeatable. I was also able to recreate this problem using the latest source from CVS.
I can't explain this. This has never been reported, and is not an issue with any of the tests or examples shipped with Boost.Threads. Can you create a simple example that reproduces this?
The simple solution would be to remove the condition variable from thread_param code entirely. This would simplify everything, and I don't really see the value anyway. All that is currently guaranteed is that thread_proxy will be called before the boost::thread() constructor is finished. But it doesn't guarantee that threadfunc() will be called before the constructor is finished.
It gaurantees that the function object is copied before the constructor finishes. With out this you have a race condition in which the user supplied function object may no longer exist by the time the thread goes to use it. Removing this wait is not an option. The only option available to you beyond using the wait is to dynamically allocate the proxie's parameter object, copying the user's function object at that time. This would require a fair amount of code changes, however, not just simply commenting out the wait. And *if* the wait is truly failing, then you have more issues than this approach will solve any way. So, let's fix the actual problem here, if we can determine what it is with a reproducable example. -- William E. Kempf