summaryrefslogtreecommitdiff
path: root/open_issues/glibc/t/tls-threadvar.mdwn
diff options
context:
space:
mode:
Diffstat (limited to 'open_issues/glibc/t/tls-threadvar.mdwn')
-rw-r--r--open_issues/glibc/t/tls-threadvar.mdwn29
1 files changed, 29 insertions, 0 deletions
diff --git a/open_issues/glibc/t/tls-threadvar.mdwn b/open_issues/glibc/t/tls-threadvar.mdwn
index e72732ab..4afd8a1a 100644
--- a/open_issues/glibc/t/tls-threadvar.mdwn
+++ b/open_issues/glibc/t/tls-threadvar.mdwn
@@ -29,3 +29,32 @@ IRC, freenode, #hurd, 2011-10-23:
After this has been done, probably the whole `__libc_tsd_*` stuff can be
dropped altogether, and `__thread` directly be used in glibc.
+
+
+# IRC, freenode, #hurd, 2012-08-07
+
+ <tschwinge> r5219: Update libpthread patch to replace threadvar with tls
+ for pthread_self
+ <tschwinge> r5224: revert r5219 too, it's not ready either
+ <youpi> as the changelog says, the __thread revertal is because it posed
+ problems
+ <youpi> and I just didn't have any time to check them while the freeze was
+ so close
+ <tschwinge> OK. What kind of problems? Should it be reverted upstream,
+ too?
+ <youpi> I don't remember exactly
+ <youpi> it should just be fixed
+ <youpi> we can revert it upstream, but it'd be good that we manage to
+ progress, at some point...
+ <tschwinge> Of course -- however as long as we don't know what kind of
+ problem, it is a bit difficult. ;-)
+ <youpi> since I didn't left a note, it was most probably a mere glibc run,
+ or boot with the patched libpthread
+ <youpi> *testsuite run
+ <tschwinge> OK.
+ <tschwinge> The libpthread testsuite doesn't show any issues with that
+ patch applied, though. But I didn'T test anything else.
+ <tschwinge> youpi: Also, you have probably seen my glibc __thread errno
+ email -- rmcgrath wanted to find some time this week to comment/help, and
+ I take it you don't have any immediate comments to that issue?
+ <youpi> I saw the mails, but didn't investigate at all