From 9933cec0a18ae2a3d752f269d1bb12c19f51199d Mon Sep 17 00:00:00 2001 From: Thomas Schwinge Date: Sun, 21 Jul 2013 15:35:02 -0400 Subject: IRC. --- .../libpthread/t/fix_have_kernel_resources.mdwn | 181 ++++++++++++++++++++- 1 file changed, 179 insertions(+), 2 deletions(-) (limited to 'open_issues/libpthread/t') diff --git a/open_issues/libpthread/t/fix_have_kernel_resources.mdwn b/open_issues/libpthread/t/fix_have_kernel_resources.mdwn index 10577c1e..4e35161f 100644 --- a/open_issues/libpthread/t/fix_have_kernel_resources.mdwn +++ b/open_issues/libpthread/t/fix_have_kernel_resources.mdwn @@ -1,4 +1,4 @@ -[[!meta copyright="Copyright © 2012 Free Software Foundation, Inc."]] +[[!meta copyright="Copyright © 2012, 2013 Free Software Foundation, Inc."]] [[!meta license="""[[!toggle id="license" text="GFDL 1.2+"]][[!toggleable id="license" text="Permission is granted to copy, distribute and/or modify this @@ -10,7 +10,9 @@ License|/fdl]]."]]"""]] [[!tag open_issue_libpthread]] -`t/have_kernel_resources` +`t/fix_have_kernel_resources` + +Address problem mentioned in [[/libpthread]], *Threads' Death*. # IRC, freenode, #hurd, 2012-08-30 @@ -19,3 +21,178 @@ License|/fdl]]."]]"""]] tschwinge: i.e. the ability to tell the kernel where the stack is, so it's unmapped when the thread dies which requiring another thread to perform this deallocation + + +## IRC, freenode, #hurd, 2013-05-09 + + braunr: Speaking of which, didn't you say you had another "easy" + task? + bddebian: make a system call that both terminates a thread and + releases memory + (the memory released being the thread stack) + this way, a thread can completely terminates itself without the + assistance of a managing thread or deferring work + braunr: That's "easy" ? :) + bddebian: since it's just a thread_terminate+vm_deallocate, it is + something like thread_terminate_self + But a syscall not an RPC right? + in hurd terminology, we don't make the distinction + the only real syscalls are mach_msg (obviously) and some to get + well known port rights + e.g. mach_task_self + everything else should be an RPC but could be a system call for + performance + since mach was designed to support clusters, it was necessary that + anything not strictly machine-local was an RPC + and it also helps emulation a lot + so keep doing RPCs :p + + +## IRC, freenode, #hurd, 2013-05-10 + + i'm not sure it should only apply to self though + youpi: can we get a quick opinion on this please ? + i've suggested bddebian to work on a new RPC that both terminates + a thread and releases its stack to help fix libpthread + and initially, i thought of it as operating only on the calling + thread + do you see any reason to make it work on any thread ? + (e.g. a real thread_terminate + vm_deallocate) + (or any reason not to) + thread stack deallocation is always a burden indeed + I'd tend to think it'd be useful, but perhaps ask the list + + +## IRC, freenode, #hurd, 2013-06-26 + + looks like there is a port right leak in libpthread + grmbl, the port leak seems to come from mach_port_destroy being + buggy :/ + hum, apparently we're not the only ones to suffer from port leaks + wrt mach_port_destroy + ew, libpthread is leaking + memory or ports? + both + sounds great ;) + as it is, libpthread doesn't destroy threads + it queues them so they're recycled late + r + but there is confusion between the thread structure itself and its + internal resources + i.e. there is pthread_alloc which allocates a thread structure, + and pthread_create which allocates everything else + but on pthread_exit, nothing is destroyed + when a thread structure is reused, its internal resources are + replaced by new instances + oh + it's ok for joinable threads but most of our threads are detached + pinotree: as expected, it's bigger than expected :p + so i won't be able to write a quick fix + the true way to fix this is make it possible for threads to free + their own resources + let's do that :p + ok, got the new thread termination function, i'll build eglibc + package providing it, then experiment with libpthread + braunr: iirc there's also a tschwinge patch in the debian eglibc + about that + ah + libpthread_fix.diff + i see + thanks for the notice + bddebian: + http://www.sceen.net/~rbraun/0001-thread_terminate_deallocate.patch + bddebian: this is what it looks like + see, short and easy + Aye but didn't youpi say not to bother with it?? + he did ? + i don't remember + I thought that was the implication. Or maybe that was the one I + already did!? + i'd be interested in reading that + anyway, there still are problems in libpthread, and this call is + one building block to fix some of them + some important ones + (big leaks) + + +## IRC, freenode, #hurd, 2013-06-29 + + damn, i fix leaks in libpthread, only to find out leaks somewhere + else :( + bddebian: ok, actually it was a bit more complicated than what i + showed you + because in addition to the stack, the call must also release the + send right in the caller's ipc space + (it can't be released before since there would be no mean to + reference the thread to destroy) + or perhaps it should strictly be reserved to self termination + hmm + yes it would probably be simpler + but it should be a decent compromise + i'm close to having a libpthread that doesn't leak anything + and that properly destroys threads and their resources + + +## IRC, freenode, #hurd, 2013-06-30 + + bddebian: ok, it was even more tricky, because the kernel would + save the return value on the user stack (which is released by the call + and then invalid) before checking for asynchronous software traps (ASTs, + a kind of software interrupts in mach), and terminating the calling + thread is done by a deferred AST ... :) + hmm, making threads able to terminate themselves makes rpctrace a + bit useless :/ + well, more restricted + + ok so, tough question : + i have a small test program that creates a thread, and inspect its + state before any thread dies + i can see msg_report_wait requests when using ps + (one per thread) + one of these requests create a new receive right, apparently for + the second thread in the test program + each time i use ps, i can see the sequence numbers of two receive + rights increase + i guess these rights are related to proc and signal handling per + thread + but i can't find what create them + does anyone know ? + tschwing_: ^ :) + + again, too many things wrong elsewhere to cleanly destroy threads + .. + something is deeply wrong with controlling terminals .. + + +## IRC, freenode, #hurd, 2013-07-01 + + youpi: if you happen to notice what receive right is created for + each thread (beyond the obvious port used for blocking and waking up), + please let me know + it's the only port leak i have with thread destruction + and i think it's related to the proc server since i see the + sequence number increase every time i use ps + + pinotree: my change doesn't fix all the pthread leaks but it's a + lot better + bddebian: i've spent almost the whole week end trying to find the + last port leak without success + there is some weird bug related to the controlling tty that hits + me every time i try to change something + it's the same bug that prevents ttys from being correctly closed + when using ssh or screen + well maybe not the same, but it's close + some stale receive right kept around for no apparent reason + and i can't find its source + + +## IRC, freenode, #hurd, 2013-07-02 + + and btw, i don't think i can make my libpthread patch work + i'll just aim at avoiding leaks, but destroying threads and their + related resources depends on other changes i don't clearly see + + +## IRC, freenode, #hurd, 2013-07-03 + + grmbl, i don't want to give up thread destruction .. -- cgit v1.2.3