[[!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 document under the terms of the GNU Free Documentation License, Version 1.2 or any later version published by the Free Software Foundation; with no Invariant Sections, no Front-Cover Texts, and no Back-Cover Texts. A copy of the license is included in the section entitled [[GNU Free Documentation License|/fdl]]."]]"""]] [[!tag open_issue_libpthread]] `t/fix_have_kernel_resources` Address problem mentioned in [[/libpthread]], *Threads' Death*. # IRC, freenode, #hurd, 2012-08-30 tschwinge: this issue needs more cooperation with the kernel 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 ..