summaryrefslogtreecommitdiff
path: root/libpthread.mdwn
diff options
context:
space:
mode:
authorThomas Schwinge <tschwinge@gnu.org>2012-11-29 01:33:22 +0100
committerThomas Schwinge <tschwinge@gnu.org>2012-11-29 01:33:22 +0100
commit5bd36fdff16871eb7d06fc26cac07e7f2703432b (patch)
treeb430970a01dfc56b8d41979552999984be5c6dfd /libpthread.mdwn
parent2603401fa1f899a8ff60ec6a134d5bd511073a9d (diff)
IRC.
Diffstat (limited to 'libpthread.mdwn')
-rw-r--r--libpthread.mdwn23
1 files changed, 22 insertions, 1 deletions
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]]