From 51c95fc11727532e3b0d98c8470a6b60907a0680 Mon Sep 17 00:00:00 2001 From: Thomas Schwinge Date: Tue, 8 Jan 2013 21:31:31 +0100 Subject: IRC. --- glibc/signal/signal_thread.mdwn | 58 ++++------------------------------------- 1 file changed, 5 insertions(+), 53 deletions(-) (limited to 'glibc') diff --git a/glibc/signal/signal_thread.mdwn b/glibc/signal/signal_thread.mdwn index 5341b1ab..c6e8d69e 100644 --- a/glibc/signal/signal_thread.mdwn +++ b/glibc/signal/signal_thread.mdwn @@ -1,4 +1,4 @@ -[[!meta copyright="Copyright © 2011 Free Software Foundation, Inc."]] +[[!meta copyright="Copyright © 2011, 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 @@ -17,6 +17,8 @@ other threads. [[!tag open_issue_documentation]] +# IRC, freenode, #hurd, 2011-04-20 + bugs around signals are very tricky signals are actually the most hairy part of the hurd and the reason they're aynchronous is that they're handled by a @@ -46,55 +48,5 @@ other threads. sure it is but does it really matter ? mach and the hurd were intended to be "hyperthreaded" - so basically, a thread should consume only a few kernel resources - in GNU Mach, it doesn't even consume a kernel stack because only - continuations are used - and in userspace, it consumes 2 MiB of virtual memory, a few table - entries, and almost no CPU time - What does "hyperthreaded" mean: Do you have a reference? - in this context, it just means there are a lot of threads - even back in the 90s, the expected number of threads could scale - up to the thousand - today, it isn't much impressive any more - but at the time, most systems didn't have LWPs yet - and a process was very expensive - Looks like I have some catching up to do: What is "continuations" - and LWP? Maybe I also need a reference to an overview on multi-threading. - Lightweight process? - http://en.wikipedia.org/wiki/Light-weight_process - svante_: that's a whole computer science domain of its own - yes - LWPs are another names for kernel threads usually - continuations are a facility which allows a thread to store its - state, yield the processor to another thread, and when it's dispatched - again by the scheduler, it can resume with its saved state - most current kernels support kernel preemption though - which means their state is saved based on scheduler decisions - unlike continuations where the thread voluntarily saves its state - if you only have continuations, you can't have kernel preemption, - but you end up with one kernel stack per processor - while the other model allows kernel preemption and requires one - kernel stack per thread - I know resources are limited, but it looks like kernel preemption - would be nice to have. Is that too much for a GSoC student? - it would require a lot of changes in obscure and sensitive parts - of the kernel - and no, kernel preemption is something we don't actually need - even current debian linux kernels are built without kernel - preemption - and considering mach has hard limitations on its physical memory - management, increasing the amount of memory used for kernel stacks would - imply less available memory for the rest of the system - Are these hard limits in mach difficult to change? - yes - consider mach difficult to change - that's actually one of the goals of my stalled project - which I hope to resume by the end of the year :/ - Reading Wikipedia it looks like LWP are "kernel treads" and other - threads are "user threads" at least in IBM/AIX. LWP in Linux is a thread - sharing resources and in SunOS they are "user threads". Which is closest - for Hurd? - i told you - 14:09 < braunr> LWPs are another names for kernel threads usually - Similar to to the IBM definition then? Sorry for not remembering - what I've been reading. + +[[open_issues/multithreading]]. -- cgit v1.2.3