diff options
Diffstat (limited to 'libpthread.mdwn')
| -rw-r--r-- | libpthread.mdwn | 43 |
1 files changed, 39 insertions, 4 deletions
diff --git a/libpthread.mdwn b/libpthread.mdwn index b31876b3..801a1a79 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 @@ -20,9 +20,44 @@ License|/fdl]]."]]"""]] Porting libpthread to a specific architecture is non-trivial. -Our libpthread is currently used by / ported to the [[Hurd]] on [[GNU -Mach|microkernel/mach/gnumach]], some [[microkernel/L4]] variants, and -[[microkernel/Viengoos]]. +Our libpthread is currently used by/ported to the [[Hurd]] on [[GNU +Mach|microkernel/mach/gnumach]], and [[microkernel/Viengoos]]. + + +# History + +There has been a libpthread port for Hurd on L4 use (working directly on L4: no +further OS personality support required), which was dead and has been removed +in commit a0bca9895bca67591127680860077b2658830e96. This had been superseded +by a [[microkernel/Viengoos]] port, which has its own branches: +`master-viengoos` (an implementation of Viengoos that runs on L4) and its +successor, `master-viengoos-on-bare-metal` (runs directly on x86-64 (and it a +bit more advanced) and provides everything that `master-viengoos` does and +more). + +There has also been an incomplete and unmaintained PowerPC port which has been +removed in commit a5387f6a45d6b3f2b381d861f5c288b79da6204f. + + +## 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 |