remove libthreads.

* hurd/libthreads.mdwn: delete file.

1 files changed, 0 insertions, 39 deletions

diff --git a/hurd/libthreads.mdwn b/hurd/libthreads.mdwn
deleted file mode 100644
index aa429d81..00000000
--- a/hurd/libthreads.mdwn
+++ /dev/null
@@ -1,39 +0,0 @@
-[[!meta copyright="Copyright © 2011, 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]]."]]"""]]
-
-`libthreads` a.k.a. C threads.
-
-**Note**: since Hurd migrated to [[libpthread]] as threading library,
-the development and usage of libthreads has been discontinued.
-
-
-
-# Internals
-
-## Threading Model
-
-libthreads 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 [[libpthread]].