Re: [Boost-users] [BOOST THREAD] Threads Spawning Unexpectedly

Subject: Re: [Boost-users] [BOOST THREAD] Threads Spawning Unexpectedly
From: Terrimane Pritchett (shon.pritchett_at_[hidden])
Date: 2009-04-26 23:27:45

On Sun, Apr 26, 2009 at 6:01 PM, Nigel Rantor <wiggly_at_[hidden]> wrote:

> Terrimane Pritchett wrote:*
> *
>>
>>  *
> *
> * What made you think that the exception was being thrown becasue the
> program is multithreaded?*

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_at_[hidden]
> http://lists.boost.org/mailman/listinfo.cgi/boost-users
>