From 9667351422dec0ca40a784a08dec7ce128482aba Mon Sep 17 00:00:00 2001 From: Thomas Schwinge Date: Wed, 10 Jul 2013 23:39:29 +0200 Subject: IRC. --- libpthread.mdwn | 43 ++++++++++++++++++++++++++++++++++++++++++- 1 file changed, 42 insertions(+), 1 deletion(-) (limited to 'libpthread.mdwn') diff --git a/libpthread.mdwn b/libpthread.mdwn index 801a1a79..0a518996 100644 --- a/libpthread.mdwn +++ b/libpthread.mdwn @@ -1,4 +1,5 @@ -[[!meta copyright="Copyright © 2010, 2012 Free Software Foundation, Inc."]] +[[!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 @@ -60,6 +61,46 @@ even if the current number of threads is lower. The same issue exists in [[hurd/libthreads]]. +### IRC, freenode, #hurd, 2013-05-09 + + braunr: Speaking of which, didn't you say you had another "easy" + task? + bddebian: make a system call that both terminates a thread and + releases memory + (the memory released being the thread stack) + this way, a thread can completely terminates itself without the + assistance of a managing thread or deferring work + braunr: That's "easy" ? :) + bddebian: since it's just a thread_terminate+vm_deallocate, it is + something like thread_terminate_self + But a syscall not an RPC right? + in hurd terminology, we don't make the distinction + the only real syscalls are mach_msg (obviously) and some to get + well known port rights + e.g. mach_task_self + everything else should be an RPC but could be a system call for + performance + since mach was designed to support clusters, it was necessary that + anything not strictly machine-local was an RPC + and it also helps emulation a lot + so keep doing RPCs :p + + +#### IRC, freenode, #hurd, 2013-05-10 + + i'm not sure it should only apply to self though + youpi: can we get a quick opinion on this please ? + i've suggested bddebian to work on a new RPC that both terminates + a thread and releases its stack to help fix libpthread + and initially, i thought of it as operating only on the calling + thread + do you see any reason to make it work on any thread ? + (e.g. a real thread_terminate + vm_deallocate) + (or any reason not to) + thread stack deallocation is always a burden indeed + 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]] -- cgit v1.2.3