summaryrefslogtreecommitdiff
path: root/glibc/signal
diff options
context:
space:
mode:
authorThomas Schwinge <thomas@codesourcery.com>2013-01-08 21:34:29 +0100
committerThomas Schwinge <thomas@codesourcery.com>2013-01-08 21:43:11 +0100
commitcd42b6144bf707fa38555bc06e267bb16db011f5 (patch)
treeddebd4ae1c845bd062261b4335a9ab7a969a3c89 /glibc/signal
parenta91114fc89dd554494801349e57bd5d29454a8b1 (diff)
parente66cb01b99b60f9483de2425bca3bb104bcc9ae8 (diff)
Merge remote-tracking branch 'fp/master'
Diffstat (limited to 'glibc/signal')
-rw-r--r--glibc/signal/signal_thread.mdwn58
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]].