IRC.
[hurd-web.git] / glibc / signal / signal_thread.mdwn
index 5341b1a..c6e8d69 100644 (file)
@@ -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]].