Austin Foxley wrote:
On 04/12/2010 12:21 PM, Natanael Copa wrote:
Smells like stdio is not threads safe?
Interesting. I supposed there could be an issue with the libc internal futex
code that replaces the old use of pthread mutexes directly. We could verify this
with a bit of work by getting the old style mutexes to compile correctly with
nptl enabled. If that fixes it, then it narrows down somewhat...
The other thing is that this might just be x86, as there haven't been reports on
other archs of these problems. Although maybe nobody else has tried it on
multi-core?
It looks like no one bothered to implement the uClibc needed stdio
locking initialization. It seems that only linuxthreads.old does this.
So both linuxthreads.new and nptl seem to be broken wrt. stdio locking.
I did not even try compile testing the below, but something like
this should help. Could you test this?
nptl: initialize stdio locking
uClibc requires the threading library to enable locking for
stdio, or the locking is not done at all.
Signed-off-by: Timo Teräs <[email protected]>
diff --git a/libpthread/nptl/init.c b/libpthread/nptl/init.c
index b651a3e..16f62f6 100644
--- a/libpthread/nptl/init.c
+++ b/libpthread/nptl/init.c
@@ -35,6 +35,7 @@
#include <lowlevellock.h>
#include <bits/kernel-features.h>
+#include <uClibc_stdio.h>
/* Size and alignment of static TLS block. */
size_t __static_tls_size;
@@ -423,6 +424,17 @@ __pthread_initialize_minimal_internal (void)
/* Determine whether the machine is SMP or not. */
__is_smp = is_smp_system ();
+
+ /* uClibc-specific stdio initialization for threads. */
+ {
+ FILE *fp;
+ _stdio_user_locking = 0; /* 2 if threading not initialized */
+ for (fp = _stdio_openlist; fp != NULL; fp = fp->__nextopen) {
+ if (fp->__user_locking != 1) {
+ fp->__user_locking = 0;
+ }
+ }
+ }
}
strong_alias (__pthread_initialize_minimal_internal,
__pthread_initialize_minimal)
_______________________________________________
uClibc mailing list
[email protected]
http://lists.busybox.net/mailman/listinfo/uclibc