IRC.

1 files changed, 93 insertions, 0 deletions

diff --git a/glibc/signal/signal_thread.mdwn b/glibc/signal/signal_thread.mdwn
new file mode 100644
index 00000000..28855dbd
--- /dev/null
+++ b/glibc/signal/signal_thread.mdwn
@@ -0,0 +1,93 @@
+[[!meta copyright="Copyright © 2011 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
+document under the terms of the GNU Free Documentation License, Version 1.2 or
+any later version published by the Free Software Foundation; with no Invariant
+Sections, no Front-Cover Texts, and no Back-Cover Texts.  A copy of the license
+is included in the section entitled [[GNU Free Documentation
+License|/fdl]]."]]"""]]
+
+[[!tag open_issue_documentation]]
+
+    <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
+      second thread
+    <braunr> (so yes, every process on the hurd has at least two threads)
+    <svante_> braunr: How to solve the asynch problem then if every process has
+      two threads?
+    <braunr> the easiest method would be to align ourselves on what most other
+      Unices do
+    <braunr> establish a "signal protocol" between kernel and userspace
+    <braunr> with a set of signal info in a table, most likely at the top of
+      the stack
+    <braunr> but this is explicitely what the original Mach developers didn't
+      want, and they were right IMO
+    <braunr> having two threads is very clean, but it creates incompatibilites
+      with what POSIX requires
+    <braunr> so there might be a radical choice to make here
+    <braunr> and i doubt we have the resources to make it happen
+    <svante_> What is the advantage of having two threads per process, a per
+      the original design?
+    <braunr> it's clean
+    <braunr> you don't have to define async-signal-safe functions
+    <braunr> it's like using sigwait() yourself in a separate thread, or
+      multiplexing them through signalfd()
+    <svante_> Regardless of the advantages, isn't two threads per process a
+      waste of resources?
+    <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.