From 5bd36fdff16871eb7d06fc26cac07e7f2703432b Mon Sep 17 00:00:00 2001 From: Thomas Schwinge Date: Thu, 29 Nov 2012 01:33:22 +0100 Subject: IRC. --- libpthread.mdwn | 23 ++++++++++++++++++++++- 1 file changed, 22 insertions(+), 1 deletion(-) (limited to 'libpthread.mdwn') diff --git a/libpthread.mdwn b/libpthread.mdwn index b31876b3..27ca0da9 100644 --- a/libpthread.mdwn +++ b/libpthread.mdwn @@ -1,4 +1,4 @@ -[[!meta copyright="Copyright © 2010 Free Software Foundation, Inc."]] +[[!meta copyright="Copyright © 2010, 2012 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 @@ -25,6 +25,27 @@ Mach|microkernel/mach/gnumach]], some [[microkernel/L4]] variants, and [[microkernel/Viengoos]]. +## Threading Model + +libpthread has a 1:1 threading model. + + +## Threads' Death + +A thread's death doesn't actually free the thread's stack (and maybe not the +associated Mach ports either). That's because there's no way to free the stack +after the thread dies (because the thread of control is gone); the stack needs +to be freed by something else, and there's nothing convenient to do it. There +are many ways to make it work. + +However, it isn't really a leak, because the unfreed resources do get used for +the next thread. So the issue is that the shrinkage of resource consumption +never happens, but it doesn't grow without bounds; it just stays at the maximum +even if the current number of threads is lower. + +The same issue exists in [[hurd/libthreads]]. + + # Open Issues [[!inline pages=tag/open_issue_libpthread raw=yes feeds=no]] -- cgit v1.2.3