Porting libpthread to a specific architecture is non-trivial.
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 Viengoos port, which has its own branches:
master-viengoos (an implementation of Viengoos that runs on L4) and its
master-viengoos-on-bare-metal (runs directly on x86-64 (and it a
bit more advanced) and provides everything that
master-viengoos does and
There has also been an incomplete and unmaintained PowerPC port which has been removed in commit a5387f6a45d6b3f2b381d861f5c288b79da6204f.
libpthread has a 1:1 threading model.
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 libthreads.
The current implementation in libpthread is buggy.
- glibc libpthread robust mutexes
- libgomp pthread attr setstacksize pthread stack min
- libpthread 1fcd93fd3c733eb19bcad8d03e65f13ec4b0e998..master-viengoos-on-bare-metal
- libpthread: CLOCK_MONOTONIC
- libpthread as glibc addon
- libpthread: __pthread_enqueue: Assertion `thread->prevp == 0' failed
- cancellation points are not cancelling threads
- libpthread dlopen
- libpthread glibc nptl testsuite
- libpthread set stack size
- libpthread timeout dequeue
- libpthread weak symbols
- packaging libpthread
- pthread atfork