From 9933cec0a18ae2a3d752f269d1bb12c19f51199d Mon Sep 17 00:00:00 2001 From: Thomas Schwinge Date: Sun, 21 Jul 2013 15:35:02 -0400 Subject: IRC. --- libpthread.mdwn | 41 ++--------------------------------------- 1 file changed, 2 insertions(+), 39 deletions(-) (limited to 'libpthread.mdwn') diff --git a/libpthread.mdwn b/libpthread.mdwn index 0a518996..fc5c0974 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 - - 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 +The current implementation in libpthread is +[[buggy|libpthread/t/fix_have_kernel_resources]]. # Open Issues -- cgit v1.2.3