path: root/libpthread.mdwn
diff options
authorThomas Schwinge <>2013-07-21 15:35:02 -0400
committerThomas Schwinge <>2013-07-21 15:35:02 -0400
commit9933cec0a18ae2a3d752f269d1bb12c19f51199d (patch)
treecc30f2d56b87d3896e460a58b76e964231c0d578 /libpthread.mdwn
parent65efe654a9cb0b682efa9bf21065469a2e9147f4 (diff)
Diffstat (limited to 'libpthread.mdwn')
1 files changed, 2 insertions, 39 deletions
diff --git a/libpthread.mdwn b/libpthread.mdwn
index 0a51899..fc5c097 100644
--- a/libpthread.mdwn
+++ b/libpthread.mdwn
@@ -60,45 +60,8 @@ 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
+The current implementation in libpthread is
# Open Issues