On Sun, Apr 26, 2009 at 6:01 PM, Nigel Rantor
<wiggly@wiggly.org> wrote:
Terrimane Pritchett wrote:
Because I have a single threaded implementation that uses boost::lexical_cast extensively without throwing any exceptions or generating any warning/errors during compilation. Secondly, boost::lexcial_cast does not guarantee thread safety - just as std::stringstream does not guarantee thread safety.
Have you checked the information that the exception is returning to you?
Yes, but if there is something specific you suggest I look for I would like input about that.
Have you got the data that caused the exception?
Yes. The data originates in a Collada document that has been vetted as sound and I have used to for testing purposes elsewhere.
Could you please elaborate as to why you think you have more threads than expected? How many? What other libraries are you using that may create threads?
The number of new threads that are generated is not predicable. I am using MSVS 2008. I can see every active thread in my application at any breakpoint. I can count how many threads are active and see what type of threads they are. I explicitly create N threads and count M threads where N is less than M. Immediately after I spawn my threads I halt execution and count how many are active and in what state they are in. At that point the only threads present are those I have spawned. I then let the app run and new threads appear which I did not explicitly create.
I am using no other threading libraries in this project. I am testing Boost Threads for the purpose of becoming my base multi-threading API as opposed to say pthreads. There is one and only one point at which child threads of the parent process are allowed to spawn - that is my intention.
A cursory glance at the lexical_cast source leads me to think that tracking down the data that caused the bad_lexical_cast to be thrown should be your first job.
Until you do that I wouldn't waste any time trying to create wrappers around libraries that may already be thread-safe.
Someone who is more familliar with the lexical_cast code may be able to say one-way or another. If you had hard evidence it was a threading issue I'd spend some more time on it, but I'd put my money on the bad_lexical_cast being thrown because it could not perform the requested conversion, and nothing to do with threads.
I have a complete single threaded implementation which executes over the exact same data - boost::lexical_cast performs exactly as it should using that same input data.
I suppose I will need you to qualify what you would consider to be hard evidence here.
Let us know how you get on with trying to track down the data that caused the exception to be thrown.
I already have done this. I get data from Collada documents as std::strings. I print them out. I have boost::tokenizer tokenize the strings. I print out the tokens. I have boost::lexical_cast convert the tokens to plain ole data types. In the single threaded implementation every cast can be checked. It is more difficult with the multithreaded application but generally the same thing is done.
Perhaps I misunderstand what data it is that you are referring to. If so, I'll find it out after correct my misunderstanding.
Best,
Shon
_______________________________________________
Boost-users mailing list
Boost-users@lists.boost.org
http://lists.boost.org/mailman/listinfo.cgi/boost-users