[[!meta copyright="Copyright © 2010, 2012, 2013 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
document under the terms of the GNU Free Documentation License, Version 1.2 or
any later version published by the Free Software Foundation; with no Invariant
Sections, no Front-Cover Texts, and no Back-Cover Texts.  A copy of the license
is included in the section entitled [[GNU Free Documentation
License|/fdl]]."]]"""]]

[[!meta title="POSIX Threading Library"]]


# Sources

<http://git.savannah.gnu.org/cgit/hurd/libpthread.git/>


# Specifics

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]], 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]].


### IRC, freenode, #hurd, 2013-05-09

    <bddebian> braunr: Speaking of which, didn't you say you had another "easy"
      task?
    <braunr> bddebian: make a system call that both terminates a thread and
      releases memory
    <braunr> (the memory released being the thread stack)
    <braunr> this way, a thread can completely terminates itself without the
      assistance of a managing thread or deferring work
    <bddebian> braunr: That's "easy" ? :)
    <braunr> bddebian: since it's just a thread_terminate+vm_deallocate, it is
    <braunr> something like thread_terminate_self
    <bddebian> But a syscall not an RPC right?
    <braunr> in hurd terminology, we don't make the distinction
    <braunr> the only real syscalls are mach_msg (obviously) and some to get
      well known port rights
    <braunr> e.g. mach_task_self
    <braunr> everything else should be an RPC but could be a system call for
      performance
    <braunr> since mach was designed to support clusters, it was necessary that
      anything not strictly machine-local was an RPC
    <braunr> and it also helps emulation a lot
    <braunr> so keep doing RPCs :p


#### IRC, freenode, #hurd, 2013-05-10

    <braunr> i'm not sure it should only apply to self though
    <braunr> youpi: can we get a quick opinion on this please ?
    <braunr> i've suggested bddebian to work on a new RPC that both terminates
      a thread and releases its stack to help fix libpthread
    <braunr> and initially, i thought of it as operating only on the calling
      thread
    <braunr> do you see any reason to make it work on any thread ?
    <braunr> (e.g. a real thread_terminate + vm_deallocate)
    <braunr> (or any reason not to)
    <youpi> thread stack deallocation is always a burden indeed
    <youpi> I'd tend to think it'd be useful, but perhaps ask the list


# Open Issues

[[!inline pages=tag/open_issue_libpthread raw=yes feeds=no]]