This is the mail archive of the
libstdc++@gcc.gnu.org
mailing list for the libstdc++ project.
Re: Thread safety clarification
- To: David Waite <mass at akuma dot org>
- Subject: Re: Thread safety clarification
- From: Benjamin Kosnik <bkoz at redhat dot com>
- Date: Mon, 12 Nov 2001 18:10:58 -0800 (PST)
- Cc: libstdc++ at gcc dot gnu dot org
Hmm. I missed the whole "November will be threading questions" email.
Oh well.
;)
> The reason for my concern is that I have a program which breaks after a
> period of load compiled with gcc 3.0.1 with a non-optimized release on
> Solaris (x86 and sparc) but not under Linux x86 - with an optimized
> build on Linux, the program breaks invariably on startup.
so:
linux -O0 +
linux -O2 -
solaris -O0 -
solaris -O2 -
I'm assuming these toolchains are all configured with
--enable-threads=posix? What's an "optimized build?" What is the lowest
level of optimization that will trigger the error? Does turning off some
optimizations allow the binary to execute correctly? See the gcc online
docs for what opts are turned on at which optimization level, and flags
that allow fine-tuning (ie turn off specific optimizations.)
> Under gcc
> 2.95.2 and its STL I don't have these problems (or rather; string's
> reference counting bug breaks me before the issue comes up),
Ok. So this never worked with g++?
> and using
> STLPort on 2.95.2 I have yet to have any problems other than extreme
> slowness.
Okay. Let's try to get this fixed then. What opts are being used with
STLPort?
Can you be a bit more specific? You're comparing a lot of stuff here.
> Any clues to help get this whole thing solved?
You'll need to post some source code that is self-contained, as small as
possible, and allows others to reproduce the problem. Without this,
helping you figure this out is pretty difficult. Look on the web
archives of this list for the last month or so for some examples, and read that commentary.
-benjamin