|author||Thomas Schwinge <firstname.lastname@example.org>||2012-11-29 01:33:22 +0100|
|committer||Thomas Schwinge <email@example.com>||2012-11-29 01:33:22 +0100|
Diffstat (limited to 'libpthread.mdwn')
1 files changed, 22 insertions, 1 deletions
diff --git a/libpthread.mdwn b/libpthread.mdwn
index b31876b..27ca0da 100644
@@ -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
+## 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]]