On Wed, 25 Apr 2001, Dhanashri P wrote:
> Hi ,
> I am using RHL 7.0 and g++ 2.96 . When using cout
> within child threads , the program hangs at cout .
>
> Here's the stack trace
>
> #0 0x400a4585 in __sigsuspend (set=0xbf7ff97c)
> at ../sysdeps/unix/sysv/linux/sigsuspend.c:45
> #1 0x4006b4b9 in __pthread_wait_for_restart_signal
> (self=0xbf7ffc00)
> at pthread.c:896
> #2 0x4006d09c in __pthread_lock (lock=0x40058ca8,
> self=0xbf7ffc00)
> at spinlock.c:126
> #3 0x400698e1 in __pthread_mutex_lock
> (mutex=0x40058c98) at mutex.c:96
> #4 0x4006c642 in __flockfile (stream=0x40058cc0) at
> lockfile.c:32
> #5 0x4003c201 in ostream::operator<< () from
> /usr/lib/libstdc++-libc6.2-2.so.3
> #6 0x804878c in thread_function ()
> #7 0x4006960e in pthread_start_thread
> (arg=0xbf7ffc00) at manager.c:274
>
> I tried the same on RHL 6.0 , g++ 2.91 and it passes
> without any problems .
>
> Please can anyone give me any info on this ..
It used to be that using the IO stream classes in threads was not a good
idea (per http://gcc.gnu.org/onlinedocs/libstdc++/faq/index.html, section
5.6):
5.6 Is libstdc++-v3 thread-safe?
Quick answer: no, as of 2.92 (eleventh snapshot), the library is not
appropriate for multithreaded access. The string class is MT-safe.
But from the above it looks like perhaps they are at least trying to
behave properly -- my guess is libstdc++ still has a few bugs. :)
You might also want to try the libstdc++ mailing lists at:
http://gcc.gnu.org/lists.html
or the libstd++ mailing list archive at:
http://gcc.gnu.org/ml/libstdc++
Jim
_______________________________________________
Redhat-devel-list mailing list
[EMAIL PROTECTED]
https://listman.redhat.com/mailman/listinfo/redhat-devel-list
