From 2bc136e680877b6a9d17d6a0e815b47775088d67 Mon Sep 17 00:00:00 2001 From: Thomas Schwinge Date: Mon, 9 May 2011 10:47:56 +0200 Subject: IRC. --- glibc/signal/signal_thread.mdwn | 93 +++++++++++++++++++++++++++++++++++++++++ 1 file changed, 93 insertions(+) create mode 100644 glibc/signal/signal_thread.mdwn (limited to 'glibc/signal') 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]] + + 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 + second thread + (so yes, every process on the hurd has at least two threads) + braunr: How to solve the asynch problem then if every process has + two threads? + the easiest method would be to align ourselves on what most other + Unices do + establish a "signal protocol" between kernel and userspace + with a set of signal info in a table, most likely at the top of + the stack + but this is explicitely what the original Mach developers didn't + want, and they were right IMO + having two threads is very clean, but it creates incompatibilites + with what POSIX requires + so there might be a radical choice to make here + and i doubt we have the resources to make it happen + What is the advantage of having two threads per process, a per + the original design? + it's clean + you don't have to define async-signal-safe functions + it's like using sigwait() yourself in a separate thread, or + multiplexing them through signalfd() + Regardless of the advantages, isn't two threads per process a + waste of resources? + 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. -- cgit v1.2.3