diff options
author | Thomas Schwinge <thomas@codesourcery.com> | 2013-01-08 21:34:29 +0100 |
---|---|---|
committer | Thomas Schwinge <thomas@codesourcery.com> | 2013-01-08 21:43:11 +0100 |
commit | cd42b6144bf707fa38555bc06e267bb16db011f5 (patch) | |
tree | ddebd4ae1c845bd062261b4335a9ab7a969a3c89 /glibc/signal | |
parent | a91114fc89dd554494801349e57bd5d29454a8b1 (diff) | |
parent | e66cb01b99b60f9483de2425bca3bb104bcc9ae8 (diff) |
Merge remote-tracking branch 'fp/master'
Diffstat (limited to 'glibc/signal')
-rw-r--r-- | glibc/signal/signal_thread.mdwn | 58 |
1 files changed, 5 insertions, 53 deletions
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 + <braunr> bugs around signals are very tricky <braunr> signals are actually the most hairy part of the hurd <braunr> and the reason they're aynchronous is that they're handled by a @@ -46,55 +48,5 @@ other threads. <braunr> sure it is <braunr> but does it really matter ? <braunr> mach and the hurd were intended to be "hyperthreaded" - <braunr> so basically, a thread should consume only a few kernel resources - <braunr> in GNU Mach, it doesn't even consume a kernel stack because only - continuations are used - <braunr> and in userspace, it consumes 2 MiB of virtual memory, a few table - entries, and almost no CPU time - <svante_> What does "hyperthreaded" mean: Do you have a reference? - <braunr> in this context, it just means there are a lot of threads - <braunr> even back in the 90s, the expected number of threads could scale - up to the thousand - <braunr> today, it isn't much impressive any more - <braunr> but at the time, most systems didn't have LWPs yet - <braunr> and a process was very expensive - <svante_> 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. - <ArneBab> Lightweight process? - http://en.wikipedia.org/wiki/Light-weight_process - <braunr> svante_: that's a whole computer science domain of its own - <braunr> yes - <braunr> LWPs are another names for kernel threads usually - <braunr> 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 - <braunr> most current kernels support kernel preemption though - <braunr> which means their state is saved based on scheduler decisions - <braunr> unlike continuations where the thread voluntarily saves its state - <braunr> if you only have continuations, you can't have kernel preemption, - but you end up with one kernel stack per processor - <braunr> while the other model allows kernel preemption and requires one - kernel stack per thread - <svante_> I know resources are limited, but it looks like kernel preemption - would be nice to have. Is that too much for a GSoC student? - <braunr> it would require a lot of changes in obscure and sensitive parts - of the kernel - <braunr> and no, kernel preemption is something we don't actually need - <braunr> even current debian linux kernels are built without kernel - preemption - <braunr> 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 - <svante_> Are these hard limits in mach difficult to change? - <braunr> yes - <braunr> consider mach difficult to change - <braunr> that's actually one of the goals of my stalled project - <braunr> which I hope to resume by the end of the year :/ - <svante_> 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? - <braunr> i told you - <braunr> 14:09 < braunr> LWPs are another names for kernel threads usually - <svante_> Similar to to the IBM definition then? Sorry for not remembering - what I've been reading. + +[[open_issues/multithreading]]. |